Solidity (Smart Contract Development) Is Hard

medium.com

6 points·alexwalther··4 comments

Coming from industrial control code in C where if you get it wrong somebody might die, solidity is safe, predictable, and expressive with well defined limitations, caveats and isms lol. It’s all a matter of perspective. If you take a craftsman’s approach to code and documentation, solidity is actually not bad at all. It’s all about letting the data structures do the heavy lifting, avoiding loops like the plague ( not a universal opinion), and writing expressively and clearly.

This seems like such an unergonomic language for developing financial programs, with hidden sharp edges.

eg. How on earth could you think it's OK to let you destroy (or permalock) coins through any mechanism other than a blatently clear semantic like DestroyCoins()? Accountants learned that lesson ages ago with the invention of double-entry bookkeeping.

Can any programmers in the space comment on whether and how newer languages improve on some of the gotchas?

There's Cairo (haven't evaluated it) and then there's Vyper, which is basically Solidity but Python

Vyper powers some big projects like Yearn

The thing here is to understand the vm. If you understand the machine and environment the machine runs on, its really not complex at all. It’s a lot like writing c or assembly for a well designed microcontroller.

Reply on news.ycombinator.com