Thank you so much for sharing, Lynnete! I watched your ZK on ink! tutorial for sub0, and I love the energy and clarity you’re bringing forward. I feel mentally
aligned with your core message, and I’m inspired to share my thoughts as well.
I feel there’s a misalignment between how Polkadot wants to present itself and how it’s currently handling decisions.
Opening the Polkadot documentation (docs.polkadot.com), one can read in the smart contracts section about being able to choose between a Rust-based language
(ink!) and good old familiar Solidity. But very quickly, the docs diverge into speaking about Solidity and Solidity only, showcasing what I interpret as a
preference for positioning Polkadot as a Solidity-enabled environment, while still taking credit for ink! being part of the ecosystem.
What astounds me, then, is the difficulty of securing funding for such an important project within the Polkadot ecosystem.
In my eyes, developers who use Solidity aren’t incentivized to deploy their apps on Polkadot. In the end, they will go where the most traction is, choosing a
chain based on similar apps in their niche, pre-selecting the community sector they believe is likely to interact with their apps.
Leaning hard on making Solidity the preferred option for Polkadot doesn’t play well with what makes Polkadot unique. Polkadot is unique thanks to the Polkadot
SDK, thanks to Parachains, thanks to XCM messaging, thanks to the Rust architecture of the whole system.
Rust, and by extension, Rust-based languages, make much more sense than Solidity to me, and that’s coming from a developer on EVM, developing in Solidity since
2020.
That exact experience of Solidity’s compiler, which checks syntax but doesn’t enforce memory safety the way Rust does, allowed me and others to deploy smart
contracts with logic flaws and vulnerabilities that only became apparent after deployment and testing.
Writing Rust is infuriating at first. But the more one writes Rust, the more they fall in love with the Rust compiler. Its verbose nature catches issues at
compile time and even provides exact solutions on how to fix them. That’s a superpower no language can currently flex as well as Rust can. I fell in love with
Rust the moment I discovered it, and that love only grows stronger as I dive deeper into the language.
For smart contracts, safety and predictability of responses and state changes seem to be the most important qualities.
I’m still quite new to ink! development, but I’ve already seen its potential firsthand. I’ve been experimenting with ink! through hands-on projects: I’m currently
building an interactive education platform about ink! programming (similar to CryptoZombies), and I recently built a multiplayer battle royale arena game for the
Polkadot Cloud Builder Party hackathon, powered entirely by an ink! smart contract. Through building these projects, I’m learning more and more, and my
preference to dive deeper into the uniqueness of ink! is growing stronger every day.
The learning experience has been eye-opening. The intersection of the Polkadot SDK and writing smart contracts in ink! is immediately apparent, the similar macro
patterns, the shared storage concepts, the familiar Rust idioms. This vertical integration is unique to ink! Solidity doesn’t give you that pathway from smart
contracts to runtime development.
Sure, ink! does lack the standardization that Solidity has. That’s to be expected with every new language, but I feel like even people who love Solidity should
support ink!.
Because developers LOVE choices. Choices and preferences are the cornerstones of developer joy, and I can’t imagine anything more boring than doing Solidity on
every chain forever. I would instead love a future where every Polkadot developer has options, choosing the right tool for the right task, the right language for
the smart contract they want.