We have just published the second part in “The Road to Core Solidity“ blogpost series: Core Solidity Deep Dive, through which we will share our direction for the language.
→ Core Solidity Deep Dive
Our goal with the series is to show the community how we see the project’s long-term roadmap shaping up. While we are confident about the general direction, there are parts about the future of the language that we would like to invite our user community to discuss and provide constructive feedback on.
We are starting this forum thread to facilitate such open discussions on the upcoming parts of the series. We request readers to take the time to go through the overview shared in the blog post above and get involved in the process going forward by sharing their thoughts below this thread.
Note:The Solidity team hosts weekly language design discussions to provide a channel for our community to meet with us and contribute to the future of Solidity. If you have issues or pull requests to discuss, or are interested in hearing what the team and contributors are working on, you can join our public team call every Wednesdays at 3PM CET/CEST. The call takes place on Jitsi: https://meet.solidity.org
Feel free to drop in and help us shape the future of Solidity.
Respectfullly, I don’t think this should be called Solidity Core. The syntax is so different from Solidity that it is an entirely different language altogether, deserving of its own name and separate compiler. Personal preference of course, but I feel like the ergonomics of the proposed new language could be better.
Core Solidity is still Solidity. It has a new type system under the hood but from programmer’s perspective it’s an extension of the current language, not a complete departure from it. They will be much closer than you likely expect. Fully sugared Core Solidity for the most part will look like Classic Solidity with small syntactic tweaks like postfix types. It’s just that the blog post naturally focuses on the added features, not on the things that will stay the same, so it may not be apparent from the examples.
The situation is not dissimilar to C vs C++ or JavaScript vs TypeScript, so in our opinion this naming is warranted and not unprecedented. We want to emphasize continuity. Solidity as it is now is not a finished language. Core Solidity is what it was meant to be.
The transition between the two languages will also be very gradual. There will be no sharp break requiring you to port the whole project in one go. To enable that we are planning to support cross-language imports and compilation of both Classic and Core Solidity contracts side by side, in the same project. I talked about this recently in my presentation at the Solidity Summit and we’ll also expand on that in one of the upcoming blog posts.
The syntax is not final. It is highly influenced by Haskell, but we intend to make it more Solidity-like in the end. I have some issues with it myself, but as the article says, we intentionally did not try to polish it yet, because it is a superficial aspect that is easy to adjust at any point in development, while getting the type system right is much harder and more important from the get go.
This thread is the very place where we expect feedback on things like this though, so if you have any specific things you would change, feel free to tell us. We won’t get into deep discussions on it yet, but already having a good idea of what users did not like will be very useful when we finally get to addressing this.
Question - I just noticed in the post that “We are already certain that we will be removing inheritance entirely.” What is the plan for code re-use/extension?
Note: The Solidity team hosts weekly language design discussions to provide a channel for our community to meet with us and contribute to the future of Solidity. If you have issues or pull requests to discuss, or are interested in hearing what the team and contributors are working on, you can join our public team call every Wednesdays at 3PM CET/CEST. The call takes place on Jitsi: https://meet.solidity.org