Solidity Gotchas — and happy solutions
What I found out when I became a solidity developer
I decided to become a solidity developer so I could talk from experience about some of the real constraints of working with the EVM. It’s one thing to speak in the abstract, it’s quite another to have the toe injuries from trying to walk the solidity path.
As a starter, let me say — in spite of the difficulties — it’s a really enjoyable learning curve. You are likely to find it especially so if your programming career started in the days when resource management was a thing, or your career has taken you along a track where you are dealing with limited compute and memory resources.
All those skills you learned to make things lean and fast come flooding back. It appeals to the bit of me that thinks most modern software is a palimpsest packed with profligate platform patterns. Sticking in a bit of assembler to liven things up is like getting to play licks from your teenage band again. Ah, the simple days.
As I have been developing a project, I have learned a lot, so I thought I would capture my experience. It’s in a few parts, and they are sort of chronological in that I encountered the learning in roughly this order.
I am leaving this trail of breadcrumbs in the hope that I shave 5 minutes of some future person’s time. Plus, there’s nothing like writing to crystallize learning…
Part 1: Maps and Arrays
Part 2: Storage, Memory and Calldata
Part 3: Compile size limitations and Libraries
Part 4: Call Stack Depth
Part 5: Compute is cheaper than storage — coming soon
