Your questions will be answered throughout the day (European time zones) on Wednesday, 17th of November 2021.
A few guidelines & tips for a smooth AMA
Feel free to post your questions beforehand to add them to the queue already! We won’t answer questions added after 17th of November and will close this thread once the AMA has concluded.
Ask questions using the blue Reply button at the very bottom.
Only ask one question per reply. If you have multiple questions, use multiple replies.
Check existing questions before you post yours to avoid asking the same question multiple times.
Avoid replying to somebody else’s post. If you’d like to discuss a related topic in more detail, create a new topic in this forum.
Keep your questions on topic; we will only reply to questions concerning Solidity and the Solidity ecosystem and will remove off-topic posts.
Topic
Ask any question you might have about the Solidity compiler, language design, Yul, the optimizer, the SMTChecker, or any other component!
Hi guys. Big fan of Solidity, was my first programming language and just love it. Was wondering if there are any features of Solidity that you think are underappreciated or underutilised by devs?
We don’t really know what people are using or not using, I think the possibility to define types and functions at file-level is not well-known. Another thing is maybe function types / function pointers you can use for callbacks. And finally (this is not related to the language but rather to the compiler), when people ask me how a certain change in the source code affects the bytecode, I usually tell them to take a look at a diff of the generated assembly (--asm), which often helps a lot.
In general, the biggest difficulty is often getting proper feedback about language features and coordinating all these changes.
For those who might not know (such as myself, first time on this forum!) where would be the best place to provide feedback and if there is anything in particular that we could do to provide the type of feedback the team is looking for.
For those who might not know (such as myself, first time on this forum!) where would be the best place to provide feedback and if there is anything in particular that we could do to provide the type of feedback the team is looking for.
We’ll be launching another language survey at the end of this year - answering it will be one way to help.
We also need more people participating in language discussions on the forum and in the bug tracker. The thing that helps the most is people sharing their actual use cases and saying how the change will affect them. In many cases we only have opinions from people on the team.
We got pretty good one-time feedback by interviewing some developers from major projects. We’ll be doing that more but it’s time consuming and not necessarily as representative of the whole ecosystem as we’d like. A big problem is getting data on a larger scale. We do not have any mechanism to track compiler/language usage of individual users because we think it’s too invasive. We often use code search engines and look at deployed contracts to try to determine how a feature is used in practice but that’s not perfect and the information is tedious to sift through.
As an individual user, I think that a forum is a very good place to post about your experiences with the language. It’s not a bug tracker so it does not have to be a bug or feature request. You can just post about what features you like and why, what you hate, what tools you use and how well they work with the compiler. This is especially useful with some details of your use case and why you do things the way you do. Maybe we should actually start such a thread ourselves to encourage people to post things like this
Was wondering if there are any features of Solidity that you think are underappreciated or underutilised by devs?
Two things I’d add to what @chriseth already said about the compiler:
SMTChecker - it’s still experimental and not necessarily something you can just fire and forget but many people do not even realize that there’s a formal verification tool built right into the compiler.
Contract metadata - when you compile a contract you get metadata that can be used to reproduce it byte for byte and provides some general, human-readable information about it. It was meant to make contracts deployed to the blockchain less of a black box and let users verify them. Many tools still just discard it though and for verification have to resort to hacks like flattening, which are absolutely unnecessary on modern compiler versions.
I would say immutables are really underutilized by new projects. First, it’s a gas optimization (storage read is 2100 gas v/s immutable read is 3 gas), and second, if you have a state variable that is not immutable, you should really consider if that variable will ever change over its lifetime–an important design choice. Examples:
If you have a fixed supply token, then the totalSupply state variable can be made immutable.
For “Ownable” pattern, the owner in most cases can be made immutable.
Another obscure feature would be call-protection for libraries, as well as using libraries with external functions as implementation contracts for proxies. Because such libraries enforce two critical design needs:
Lack of state variables.
Enforce that functions (part of the external interface) that can modify state can only be delegatecall-ed.
