AI generated summary and insights from Alcueca tweet

Unroll Thread for the Tweet

Cairo Development Experience Report

Overview

This report summarizes the development experience of building with Cairo on Starknet, based on feedback from developers transitioning from Solidity and working on real projects.

Learning Curve

Positive Aspects

• Prior Solidity knowledge transfers well to Cairo
• Basic functionality can be achieved without deep understanding of Cairo's internals
• Core language concepts (variables, control flow) are approachable

Initial Challenges

• Documentation inconsistencies between:
  • The Cairo Book
  • Official tutorials
  • Compiler documentation
• Learning resources sometimes conflict on basic concepts like mappings/dictionaries

Development Environment

Setup

• Dev tools installation process is straightforward
• Basic project setup is manageable

Common Pain Points

Import System

• Requires explicit imports for all functionality
• Missing import suggestions makes development tedious
• Need to import multiple traits and types for basic storage operations
• Often unclear which traits need to be imported
• Developers can get blocked when unsure about required imports

Type System

• Constructor arguments type constraints can be limiting
• Type casting knowledge required for basic operations
• Address handling requires specific imports and conversions
• Creating test addresses requires specific syntax:

  let holder: ContractAddress = 1234.try_into().unwrap();

Debug Experience

• Error messages can be cryptic or misleading
  • Example: "Type not found" errors may point to implementation issues elsewhere
• Basic operations like printing addresses to console can be challenging
• Testing and debugging require workarounds

Contract Development

ERC20 Implementation Experience

Easier Aspects

• Basic token functions (mint, transfer) are straightforward
• Constructor implementation is achievable with proper casting

Challenging Areas

• Nested mappings (e.g., for allowances) require additional effort
• Storage patterns differ from Solidity
• Event implementation requires separate consideration

Community Support

• Active Discord community
• Community helps with workarounds and solutions
• Essential for overcoming documentation gaps

Recommendations for Improvement

1. Better IDE support with import suggestions
2. More consistent documentation across official sources
3. Clearer error messages
4. Simplified import system for common operations
5. Better debugging tools and console output support
6. More comprehensive examples for common patterns

Conclusion

While Cairo offers a viable path for Starknet development, the developer experience has significant room for improvement. The learning curve is manageable for experienced Solidity developers, but tooling and documentation improvements would greatly enhance productivity.

Feedback from @enitrat

Cairo Import System Pain Points:

• Requires explicit imports for all functionality, including basic storage operations
• Developers need to import multiple components (8+ traits and types) for common tasks
• No IDE import suggestions, making it difficult to know what to import
• Can completely block development progress if you can't determine the required trait
• Would be significantly improved by adding import suggestions in the IDE

The core issue is that Cairo's strict import requirements, combined with lack of tooling support, creates unnecessary friction in the development process - especially for newcomers who may not know which specific traits and types they need to import.

IDE:

• Linter is slow
• Auto completion is slow and bad
• No auto import
• No trait import suggestion

Actual programming exp:

• It is constantly changing, it's hard to follow
• We miss simple examples we can copy/paste
• Error messages could be more helpful - e.g., suggesting missing trait derivations for storage maps

Really impressed with the progress so far. As I see the progress of competitors that allow to prove Rust or a whole Risc V architecture with decent performances I start to think that Cairo must really specialize as a smartcontract language, we have an opportunity to really provide something 10x better. Being 10x faster is not enough when everything is already fast.

Not as a Cairo contract developer, but as a Cairo language developer:

Hi I am the author of WASM-Cairo.
WASM-Cairo used by Cairobook and Starklings.app for in-browser Cairo code compiling and running.
Recently I am updating it to support 2.8.2 for Shinigami, but I found some added features(such as multi thread) cause a little hard to do this work.
So maybe before adding a new feature, consider whether this feature can be made no_std and support WebAssembly will be very helpful.
Thanks!

Components are very cumbersome.

For one, it takes way too many steps to import and use a component - importing it, correctly using the component! macro, declaring public and/or private impls, correctly adding it to struct Storage and also to enum Event. Furthermore, you need to know the internal name of the component impl (because of the #[embeddable_as(ComponentImplName].

To illustrate the point, here's a basic ERC20 token generated by OZ's Cairo wizard:

#[starknet::contract]
mod MyToken {
 use openzeppelin::token::erc20::ERC20Component;
 use openzeppelin::token::erc20::ERC20HooksEmptyImpl;
 component!(path: ERC20Component, storage: erc20, event: ERC20Event);
 #[abi(embed_v0)]
 impl ERC20MixinImpl = ERC20Component::ERC20MixinImpl<ContractState>;
 impl ERC20InternalImpl = ERC20Component::InternalImpl<ContractState>;
 #[storage]
 struct Storage {
 #[substorage(v0)]
 erc20: ERC20Component::Storage,
 }
 #[event]
 #[derive(Drop, starknet::Event)]
 enum Event {
 #[flat]
 ERC20Event: ERC20Component::Event,
 }
 #[constructor]
 fn constructor(ref self: ContractState) {
 self.erc20.initializer("MyToken", "MTK");
 }
}

If I didn't know where to copy-paste this from, I'd go crazy trying to figure out all the details.

Another pain point with components is that it's impossible to overwrite single fn in the main contract. It's a common use case people ask about all the time (e.g. custom transfer/transfer_from on an NFT contract). The only way is to reimplement all the component's functions.

Here are my top 5:

• Sometimes hard to debug, especially in a multicontract environment.
• Errors can be cryptic and confusing.
• Inheritance via components can be messy (limited workaround for overriding functions, repeated code, component! + impls + importing storage slots and events) and can lead to issues (e.g. you forget to use some impl).
• A lot of code bloat that kills readability and it is just there for the sake of the language spec. This is just a general point that can be applied to many places.
• No interface inheritance. I would like to see something like this:

  #[starknet::interface]
  trait ISomeInterface<TContractState>: IBaseInterface<TContractState> ...

There are a few things that I love (and would like to see more easy-to-use features like this):

• Native upgradeability (can't stress this enough)
• Dependency management via Scarb

Features merged in the corelib can be too long to appear in a release. For example, hex-print is merged since 2 months but is still not available :(

Adding on to Development Environment:

• For devs, who don't own a Mac (very common in India and other Asian regions), have to double boot their Windows system to have Linux installed to use Cairo
• This acts as a pain point to onboard students as most of them do not want to double boot their systems or do not know how to
• We end up losing more than half of audience's interest here
• This might seem like a trivial thing, but ends up being a huge pain point while giving workshops and live coding tutorials
• Some still struggle with environment setup (mostly people who have never used Rust)

The Vec data structure is not well designed:

• It can only grow (can't shrink)
• No way to pop_front / pop_back
• It lacks a lot of useful methods
• Thus it's not really a Vec as one would expect; which is quite misleading

The discussion about Vec arose last week with @enitrat because I was checking my understanding of how Vec behaves in storage. I was doing a Cairo workshop at School42 in Berlin and I wanted to do small demo of a pseudo VM with first-in-last-out stack and a bunch of opcodes. During the workshop we implemented only POP and PUSH but the tests failed when we added more opcodes to the program. I quickly realized that my expectations from Vec weren't correct. You can see what happens really under the hood here in the workshop branch in the test, where vec refers to the real Vec in storage, and stack refers to the fake stack I keep track of, as I artificially kept track of the length. This weird behavior takes place because I am using the method mentioned here modify_nth_address.

Later I saw that there's a section about an implementation for a stack here, but I think it should also be doable with a Vec.

I believe smart contracts would really benefit from regular methods for Vec because something simple such as whitelisted addresses could be nicely stored in a such a storage item.

I think the Cairo team should look into giving vectors more flexibility. As manipulating a Vec<T> is kind of impossible. For instance, I want to loop through a Vec<T> and then delete an element in the vector.

This is something that was possible with Alexandria List.

See the following storage variable:
I want to be able to loop through user_locks and remove an element from the Vec<ContractAddress>
user_locks: Map<ContractAddress, Vec<ContractAddress>>

But since I can't manipulate Vec<T>, I am forced to change to this:

user_locks: Map<(ContractAddress, ContractAddress), bool> which is not the best option for what I intend to do.

Make a end-to-end tutorial on how to add a libfunc (which files to change, how to test) to Cairo so we can PR optimisations or new features.

This literally makes Cairo 10X because we can 10x (or even more) the performance of some functions.

Make all core library public and let us own it / do what we want with it.

Give traceback on exact line that fails to avoid "Error: Option: unwrap failed" without knowing which one when testing.