Rust > Solidity: Data Doesn’t Lie

[peterw]

Polkadot Hub is coming in less than two months. For this current strategy of Polkadot, getting new developers to build products (dApps) on the Hub is crucial. The more developers building products, the more usage is brought to DOT’s token.

Currently, the assumptions have been that Solidity dominates in the smart contract field bringing guaranteed adoption pathways to the Hub. If Solidity dominates we would expect the data to show:

• Solidity has significantly more full-time developers over alternative smart contract choices.
• Solidity / EVM ecosystems bring in more new developers than non-Solidity ecosystems.
• Solidity developers like to explore (adopt) other EVM-compatible ecosystems.

Utilizing the most comprehensive data-set available for Web3 developers, developerreport.com by Electric Capital, we can confirm if these statements are true, and if Solidity’s “dominance” exists.

Smart Contract Choices

Before exploring the data, it’s important to clarify the main smart contract choices in Web3. There are two mainstream choices available:

• Solidity on EVM
• Rust on various VMs (usually WASM)

There are other choices, but the data is limited and shows that these are the only options worth discussing.

There is also Move that is used by Sui and Aptos. However, this has a relatively small developer base still, and is ultimately built-on Rust, powered by Rust, and inspired by Rust.

Parity was one of the first companies to recognize the importance of a Rust smart contract, creating the oldest Rust smart contract language in Web3, ink!, right next to Solana.

Full Time Developers

The first expectation for Solidity to dominate is that there should be significantly more Solidity developers than Rust developers (in Web3).

https://developerreport.com

Of the top ecosystems sorted by full-time developer count, we see that a large portion of those ecosystems use Rust smart contracts directly.

Rust-based smart contracts make up 45.5% of these ecosystems, while 40.9% are EVM based.

If we count the ecosystems powered-by Rust (e.g., Aurora & Sui), we find that 52.4% are built on Rust, while 47.6% are non-Rust (this includes EVM chains, Cardano, and Bitcoin).

In current market conditions, the EVM stack has ~4,686 full-time developers, while Rust-ecosystems have ~3,963 full-time developers.

So, of the top-20 ecosystems, more of those ecosystems use Rust smart contracts than EVM and the most popular (by devs) are powered by Rust. Additionally, total EVM developers and total Rust-developers are similar.

New Developers

Once again, Polkadot Hub needs to attract as many new developers as possible to start building dApps and products. For Solidity we would expect the data to show that EVM-based chains bring in significant amounts of new developers, showcasing the “guaranteed adoption pathways” for the Hub.

Something interesting happened in 2024:

https://www.developerreport.com/developer-report?s=solana-became-the-1-ecosystem-for-new-developers-in-july-2024

Ethereum and its L2s had reigned for 8-years in new developer adoption counts. But in 2024, that changed. Solana, using Rust-contracts, surpassed Ethereum and its L2s by over 1,000 new developers. We see Ethereum (and its L2s) had a steep decline. Aptos, powered by Rust, was also able to bring in more new developers than Ethereum.

https://www.developerreport.com/developer-report?s=solana-was-the-1-ecosystem-for-new-devs-in-2024

If we go deeper and look at the specific numbers, we see Solana surpassed Ethereum and its L2s by over 1,000 new developers. By following the chart, we see that the ecosystems bringing in the most new developers are mostly Rust ecosystems. Sui and Aptos use Move, but that is built on Rust and inspired by Rust. Arbitrum is EVM, but they also support a Rust smart contract language (Stylus).

By adding up the total amount of new developers that Ethereum and its L2s brought in, we get about 10,000. While Rust ecosystems (EXCLUDING Sui and Aptos) brought in close to 14,000 new developers. So, Rust-ecosystems saw 30% more new developers than the EVM / Solidity ecosystems.

Multi-Chain Developers (do developers deploy elsewhere)

The assumption is that because Solidity has existing developers, then Polkadot Hub will be able to access that existing developer pool. However, for this to happen we need to know if Solidity developers have a tendency to deploy on other chains.

https://www.developerreport.com/developer-report?s=let-s-look-at-the-percentage-of-shared-developers-across-different-chains

This table says: “of the developers that deployed on [for example] Avalanche, this percentage also deployed on Eth Mainnet, Optimism, etc.”

What it shows is that most Ethereum L2 developers deploy only on Ethereum Mainnet and their original L2.

Ethereum Mainnet developers have the lowest exploration, and mostly deploy only on Ethereum Mainnet.

Ethereum Mainnet is where most of the Solidity developers are. According to Electric Capital, Base is the second most popular, but also say that most “Base deployers tend to stay on Base” (src).

The data also shows that “74% of Multi-chain developers work on EVM”. (src) Showcasing that EVM does have strong network effects, relatively speaking. However, we see that a small percentage of “multi-chain developers” deploy anywhere beyond Ethereum Mainnet and their original L2. Additionally, Base and Ethereum Mainnet have the most Solidity developers, but they also are the ecosystems that tend to deploy only in their ecosystem.

To wrap-up this point, a majority of Solidity developers only deploy on Ethereum Mainnet, and their original L2.

Why Do We Care?

Polkadot Hub is supposed to launch in December, and getting new developers to build products is of utmost importance. Currently, Polkadot’s native Rust-smart contract language and only PVM-compatible language (ink!) is fighting for continued development. Not for the sake of ink!, but for the sake of being able to bring in as many developers as possible to build products and more usage of DOT.

The assumption was that because “Solidity clearly dominated” we don’t need Rust smart contracts (ink!). But, as we’ve seen those assumptions were not correct. Rust-based ecosystems have comparable amounts of developers, and brought in significantly more new developers than EVM-ecosystems. Additionally, the majority of Solidity developers don’t like to explore other ecosystems, meaning Polkadot Hub’s chances of bringing in existing Solidity developers is low.

Arguments Against ink!

There are some recurring arguments against ink!, including that it doesn’t have enough adoption, it’s not worth the price, and that ink! causes fragmentation in our ecosystem.

First, yes, ink! does not have tremendous amounts of adoption. But that’s directly correlated to Polkadot’s struggles and the lack of a Polkadot Hub. ink! is Polkadot’s native smart contract language, but there has never been a Polkadot-native solution to deploy ink!. Additionally, ink! is Rust that is expanded to work on Polkadot. Which, as we’ve seen, Rust is better at bringing in new developers than Solidity is. In other words, Rust’s brings better adoption pathways to the Polkadot Hub.

Leading to the next point, if Polkadot Hub needs more new developers to create products, and Rust is better at bringing in new developers, then why is ink! not worth it? ink! gives Polkadot Hub access to a much larger pool of developers (5.1 million) and enterprises than Solidity does. Additionally, ink! is the only language currently capable of supporting PVM at Hub’s launch – a selling proposition for someone to build on the Hub, but also a way to start battle-testing PVM in production.

We’ve also heard that ink! causes fragmentation. But, multiple deployment pathways doesn’t mean fragmentation. Ultimately, Solidity and ink! converge on one point: “deploy smart contracts to Polkadot Hub”. By supporting both Solidity and ink!, we expand the top of our funnel leading to one point – products on the Hub. Additionally, thanks to the awesome work by the ink! Alliance, ink! has Solidity-ABI compatibility allowing Solidity and ink! to interoperate, and even allows ink! to use tools like Metamask. Lastly, ink! helps reduce overall ecosystem fragmentation by natively supporting XCM – the only language to do it in a practical way.

So, does ink! guarantee that it will bring in new developers to Polkadot Hub? Definitely not. There has to be more fundamental selling points in Polkadot itself. However, by having Rust we can significantly reduce friction for bringing in new developers. This is because it’s easier for developers and enterprises to explore Web3 if they can do it in a technology they already know. Solidity is also very niche and only useful to Web3, while Rust is useful to every technical industry. So, a developer would be more willing to learn Rust (the world’s most admired language) to explore Web3 as it is useful everywhere – while Solidity is only useful in Web3.

Polkadot has always been Rust-first, it’s the reason so many of us developers are here.

Conclusion

Does ink! guarantee Polkadot Hub’s success? No. But Solidity doesn’t either. The data shows that Rust is comparable in Web3 developer count, and is much better at bringing in new developers to Web3 – a crucial piece to the Hub’s success. Only having the ability to build in Solidity or ink! isn’t enough to bring in developers. However, having the ability to build in Rust means less-friction for the 5.1 million Rust developers, and the large amounts of industries and enterprises that already use and trust Rust. Solidity brings in foundational Web3 infrastructure, but ink! helps bring in more new developers to access that infrastructure – they both are important.

Data doesn’t lie. Rust smart contracts on the Hub will do a better job at bringing in new developers. But this will only happen if the ink! Treasury proposal passes. As Electric Capital says “Developers are a leading indicator of value creation.” So shouldn’t we do everything we can to bring in new developers to build on Polkadot Hub?

Go R0GUE

Appendix

• All data can be found at: developerreport.com
• ink! treasury proposal: https://polkadot.subsquare.io/referenda/1773
• AAG Version: https://x.com/TheKusamarian/status/1981994137634357281

[_rich]

Nice work.

[sorpaas]

This has been my observation as well (some previous discussions, specially see section “A step back of the strategy”).

I would however focus more on the more fundamental problem – which is that the EVM L2 competition is as intense as you can imagine. The planned deployment of Revive EVM on Polkadot Hub is slow. Even if we take the Revive roadmap all the way to the end, a few other chains already do compiled EVM, and much better than the EVM->PVM strategy. The current Polkadot Hub strategy has no advantage in the competition field, no matter now or in the future.

Regarding “Rust > Solidity”, I would say it’s more like “ink v5 > ink v6 > Solidity”. “ink v6”, which migrated to Revive, contains a lot of “junk stuff” that is not needed due to the EVM integration. Things which may make sense with EVM standalone, but are just ecosystem burden in the Rust ecosystem, and they will hunt us for eternity.

Your data, for the adoption of Rust smart contracts, is perhaps to a great extent due to Solana. Solana really showed us what a successful ecosystem, and a non-EVM deployment could have been, if we haven’t been making those serious strategic mistakes.

[peterw]

To continue this thread, there is now this super concrete example: https://x.com/Lynette_mwangi/status/1990727033299595511?s=20

Noir circuits (ZK) being generated natively in ink! v6 (PolkaVM backed). This results in ink! contracts being 25% more gas efficient, and has a 45% smaller binary size than the alternative Solidity version.

Here is a quote directly from the implementers:

Type Safety is a Superpower: Rust’s compile-time guarantees caught numerous subtle bugs in field arithmetic and proof handling that would have been runtime failures in Solidity.

Even though two of our proposals have been rejected, we aren’t giving up on ink! – expect more. Polkadot Hub needs both Solidity and ink!. Even in an unoptimized setting as @sorpaas rightfully pointed out, ink! still shows better performance AND more secure contracts than Solidity.

[sourabhniyogi]

I would like to see Rust Smart Contract, not in ink! form but in Move form. In particular, a JAM Move Service.

In the same way as Solidity devs have a write once, deploy everywhere mindset now, it will be 10x easier to get a Move Rust developer who thinks the same thing because there is SUI + Aptos. JAM is set up to not have the “chain+language” association anymore – it will almost certainly be a rollup host to Solidity/EVM chains, Substrate and… Move

Move has all the beauty that Polkadot/Substrate has had, and we can develop our own dialect that has whatever is missing in SUI + Aptos that can take advantage of JAM’s awesome architecture. The #1 feature Move sells Rust developers on is the obvious one on avoiding the double spend problem, which it does with Rust does way better than Solidity ever possibly could.

ink! is like Microsoft’s mobile operating system in a world where Apple and Google already secured their position – Microsoft had to let go of the idea that there would be a Windows Mobile OS. It did just fine.

I don’t know exactly what your “ink! is way better than Move because {…}” but write it out as if your old dog’s life depended on it and then explain why it couldn’t be done in Move, why it couldn’t be done in a Move JAM Service. I really would like to know!

You have to learn to let ink go and take whatever it is you loved about it and put it somewhere else, where Move is a pretty good starting point. Loss aversion and the sunk cost fallacy is very real, and probably some kind psychotherapy may be required, like putting an old dog to sleep =( and waiting a bit before getting a new puppy =P.

I do believe a JAM Move Service worth doing, and can easily win over new developers who find the alternative ( Solidity ) a ridiculously tattered minefield of gotchas and tastelessness.

It’s not too late, in fact, its a perfect time to do it, like, right now.

[davidsemakula]

@sourabhniyogi

I would like to see Rust Smart Contract, not in ink! form but in Move form.

Move is not Rust though, how exactly can you have a “Rust smart contract in Move form”?
Or did you mean that you don’t want Rust smart contracts but want Move contracts instead? That would at least be more coherent.
Ditto with all the other stuff about “Move Rust“ developers. Move != Rust, so it’s hard to follow your other arguments if you conflate the two this way.

[peterw]

I’ll explain this simply.

ink = (equals) Rust.

As someone that deeply believes in the Rust ecosystem, I want to build smart contracts in Rust.

Move != (does NOT equal) Rust.

Not sure why Move is brought into this conversation. Move is not compatible with pallet-revive. Efforts have been (kinda) started, but making it production ready is going to cost a lot of money, and a lot of time. So, Polkadot Hub is coming in December (meaning no-time), and Polkadot treasury is depleting rapidly (meaning no funding).

ink! on the other hand was built by the same people who built Polkadot (Parity, and now ink! alliance). It’s compatible with pallet-revive, and is the most technically capable smart contract language for using Polkadot.

[sourabhniyogi]

Its about developers. You are welcome to call me an idiot, I’m used to it =)

Good luck!

[_rich]

Nobody is using any derogatory unprofessional terms or references, except possibly yourself. What would be helpful would be to understand the rationale behind your statements, particularly when counter arguments and rationale have been presented. Many thanks.