Solidity is Splitting in Two: Road to 1.0 and Beyond

Why this isn’t just a version bump

After years of (technically) being in a public beta, Solidity is finally preparing for something it hasn’t dared to do for a decade: hit version 1.0, the first official stable version of the language. But it wouldn’t be the blockchain world if we didn’t have a fork once in a while.

Classic Solidity will continue down the 0.x path we know today, and Core Solidity will be a clean slate redesign, intended to take over as EVM’s official language version for times to come. It’s not just about updating the syntax (although that will be a thing as well), but it’s also about fixing deeper issues that had stunted the development in the past.

Two paths, one language: Classic vs. Core

Here’s the plan:

Solidity Classic will continue to get updates, versioned as 0.x, for the foreseeable future, with a focus on incremental cleanups, as well as introducing as many new features as possible with the old design. It will (mostly) stay the Solidity we all know and (perhaps) love, with some developer experience and syntactic changes in preparation for the release of Solidity Core.
Solidity Core will be a complete revamp of the language type system. While it will look and feel like Solidity Classic, it will (according to the team) be much more minimalistic and flexible as opposed to Solidity Classic.

The goal seems to be not to run both versions forever. It looks like they will keep Solidity Classic around while Core stabilizes, giving developers a gradual migration path. Both versions compile down to the same EVM-compatible backend. That makes this less of a fork and more of a transition period.

Core promises (pun intended)

Here are the most exciting features so far:

Generics → as someone who experienced generics getting introduced in Golang after years of waiting, this is just amazing. Having generics will make reusable logic much more elegant.

// Note: this is just an example and not an actual syntax
struct LinkedListNode<T>{
	T value;
	LinkedListNode<T> next;
}

Algebraic data types & pattern matching → found in Rust, these two features together will massively help with the explicitness of branching and different case handling scenarios.

// Note: this is just an example and not an actual syntax
// Algebraic data types, e.g. more expressive enums
type PaymentResult =
    Paid(uint amount) |
    Refunded(uint amount, address to) |
    Failed(string reason);

// Pattern matching, e.g. (finally) switch-case statements
match paymentResult {
  Paid(amount) => { ... }
  Refunded(amount, to) => { ... }
  Failed(reason) => { ... }
}

Standard library → every Javascript developer probably gasped in awe to this, thinking Solidity would finally get their favorite Array/Object/insert-data-structure functions, but this will be way more than that. Things that we commonly import from OpenZeppelin, like the SafeERC20 or Proxy-related libraries, could become part of the language by default.

Together, these features don’t just make Solidity better, but they modernize it greatly. They align it more with languages built for safety and developer sanity, both qualities that dApps with many millions in TVL have craved for so long.

Community pulse

Naturally, the community’s reaction has mostly been a mix of excitement, caution and healthy skepticism.

A few other people, like Paradigm’s Georgios Konstantopoulos and Distributed Lab’s Artem Chystiakov, would prefer if Solidity compiler team focused more on the underlying speed, memory and gas consumption issues, rather than playing with new syntax and features, which is also a perfectly valid point.

Georgios Konstantopoulos' comment on "The Road to Core Solidity" Tweet

Artem Chystiakov's (Arvolear) comment on "The Road to Core Solidity" Tweet

Personally, I think that pushing the compiler team to improve speed and memory is important, but those improvements are likely to come anyways. Allowing the team to modernize the language through new features, to bolster Solidity’s expressiveness and ergonomics for the long term, is, to me, more important in the long run. I could be wrong, but regardless, on a large enough time scale, these roads will converge.

What this means for devs and the broader ecosystem

We’re not facing an either-or situation yet. Classic and Core will coexist for a while. The best thing you can do now is prepare with intention:

Stick with Classic where it makes sense. Classic is and will be the most stable environment for the foreseeable future.
Explore Core slowly. Try it for internal tools or experimental projects whenever these new features become available.
Provide feedback. Core’s design is open to feedback. Raise issues, suggest improvements, brainstorm publicly. This is a rare chance to shape a language’s future.

Closing Thoughts