My Experience with ink! and Why Rust Smart Contracts Matter for Polkadot

[Lynette]

I’m writing to share my experience developing with ink!. After building a cryptographic application using ink! v6, I believe Rust smart contracts are fundamental to what makes Polkadot unique and competitive.

I started learning ink! when I had about a year of Rust experience. I had been using Rust to program cryptographic systems. I have taken an interest in programmable cryptography and privacy-preserving on-chain applications, and I lean more towards Rust for their development. As a Rust developer, it has been easier to learn ink! since the syntax was familiar. The ink! documentation is well-detailed and provides clear explanations on ink!’s unique attributes and macros, alongside exhaustive ink! examples that demonstrate the implementation of the latest updates.

Additionally, having attended Polkadot Blockchain Academy 7, I quickly realised that programming pallets for the Polkadot SDK has a similar syntax to ink! smart contracts. Both use the same Rust macros pattern, and both have similar storage patterns. For me, this directly affected my experience in PBA’s protocol track since I transferred my experience with ink! to the assignments.

Rust is necessary for smart contracts because Rust’s philosophy heavily aligns with smart contract needs. Smart contracts manage value that can’t be rolled back, and any bugs are expensive. Rust was designed for systems where correctness and memory safety are critical. This is also necessary when writing cryptographic code, and as a result, I have come to value using Rust. Its type system makes it easier to prevent bugs in production, which is especially necessary for privacy-preserving dApps.

Since Polkadot has ink!, it makes it a suitable environment to build privacy applications and integrate other Rust-based cryptographic primitives seamlessly. Writing smart contracts for these applications is more efficient when developers can use Rust

Rust smart contracts are important for Polkadot because they attract the right builders. Rust developers care about correctness, performance, and long-term maintainability. Rust is efficient for the builders creating protocols that will make a difference. Additionally, since Polkadot 2.0 is more focused on products, Rust smart contracts integrate seamlessly with Polkadot’s design and are therefore instrumental to realising this vision.

[KilianSolutions]

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.

[Cecilia_Mulandi]

Thank you @Lynette and @KilianSolutions for sharing.My journey has been quite similar. I actually started with Solidity, but very quickly realized that the cryptography concepts I was exploring needed a language that offered more control, safety, and precision. That is what pushed me to learn Rust. And once I got comfortable with it, I completely fell in love with the language; the compiler, the guarantees, the patterns, everything.

That path eventually led me into PBA-X and later PBA7, where I finally got deep exposure to the Polkadot SDK. Because I had already written some ink!, moving between smart contracts and runtime development felt surprisingly natural. The alignment in macros, storage patterns, and idioms really makes the learning curve smoother.

Since then I have been experimenting a lot, including building iVF, and the more I build, the more convinced I am that Rust based smart contracts are one of Polkadot’s biggest strengths, especially for cryptography heavy or privacy preserving applications.

I also want to highlight how good the developer support around ink! has been. As I experiment and go through the documentation, I have found that raising issues and getting clarity or fixes is straightforward. It feels like a language the community, myself included, is genuinely excited to work with for all the right reasons.

[Lukk]

Thank you all for sharing your thoughts.

After attending PBA7 and learning about Ink!, I immediately saw the potential it unlocks and the advantages it can offer Polkadot developers. That is why I found myself eager to contribute to the Ink! ecosystem after PBA.

Substrate is Rust-based, and once you constrain yourself to Solidity’s type system, you lose much of the richness and expressiveness that the SDK provides. You cannot represent complex Rust structs or enums (which are extremely common) using Solidity types, nor can you interact with the runtime using native SCALE encoding and decoding. Precompiles may appear to solve part of this, but exposing immutable, simple-type interfaces for pallets that evolve over time and use complex data structures is fundamentally difficult. A good example is the XCM precompile: it is incredibly powerful, yet you cannot interact with it natively from Solidity because SCALE is not available there.

Ink!, on the other hand, integrates all of this (and more) natively.

This is one of the reasons to think that Ink is the way to go, If we can convince people the power that this ecosystem has and how we can harness it with Ink!, I think we will be in a good track.

[anataliocs]

I understand why Solidity is being supported in PolkaVM. Platforms shouldn’t necessarily be prescriptive and hand down ivory tower pronouncements about how developers should build.

The majority of TVL currently is locked in EVM-compatible smart contracts built primarily with Solidity.

That being said, I 1000% agree with your sentiments @Lynette

The cost of failure is so much higher in smart contracts then in web apps. As you succinctly phrased it, there are no easy rollbacks on-chain.

There’s no feature flag to flip off, there’s no canary deployment to test the waters. Smart contract development has more in common with firmware development then web dev. The cost of failure is extremely high and rolling out a fix is easier said then done.

Smart contract development needs a systems programming language. You want an extremely strict compiler. Solidity’s never-ending parade of security exploits has conclusively demonstrated that relying of “developer vigilance” is insufficient.

Smart contract implementation details are public and their interface is exposed globally with the whole internet population acting as a cybersecurity Red Team. And the financial incentives to exploit smart contracts are high enough to attract the most sophisticated attackers.

We need Procedural Macros that act as explicit guardrails. We need ink!

[N1ghtStorm]

I’ve been developing with ink! for more than half a year now. The project I’m working on hasn’t been announced yet, but the development is moving forward actively and with great momentum. I want to express my sincere gratitude to the teams behind ink!, pop-cli, and ink-ui — thanks to your work, I can write smart contracts in Rust.

I value Rust immensely for its safe and expressive type system; it’s an outstanding language for blockchain development. To be honest, I felt a bit lost when I first tried building for Polkadot using Solidity and pallet-revive — the early limitations were significant. ink! was a true lifesaver.

I’m deeply grateful to the entire ink! development team.

[OlahFemi]

I support all what @Lynette and the others have said here. I’d also like to add that, from my experience teaching ink!, developers who already have exposure to Rust tend to get excited about the prospects of building with something so familiar and reliable. We should definitely give them this and allow the “ink! ecosystem” to flourish.

[thewoodfish]

Thank you @Lynette for the detailed feedback. I started using ink! right from it’s inception. I was excited that it was “Plain old Rust” and the barrier of entry for Rust developers (especially myself) had been obliterated, for good. Ink! is easy, intuitive and developer friendly. Thanks to rust primitives like macros, a lot of things have been abstracted away and we can focus on writing good business logic. Speaking of good logic, an example is handling & returning errors (compared to solidity). Now that is all dev experience.
All the above is a scratch compared to the out of the box underlying benefits Rust provides, e.g memory safety and the likes. Ink! literally makes smart contract development easy by taking away (almost) all the ugliness. Even a non-Rust developer can take it as a simple DSL and still write good contract logic (AND DEPLOY IT) because the dev interface is so good (part thanks to Rust abstractions).
Ink! is definitely a great contract language i’d love to see more adoptions, interoperability with other infra and growth.
Gracias!