albertyw/albertyw.com

View on GitHub
app/notes/20181117-0909.md

Summary

Maintainability
Test Coverage
Solidity Review

solidity-review

1542445796

I took Solidity for a test drive a few months back to try to understand the
hype behind it, ethereum, and the crypto space in general.  While I'm no expert
and I haven't been keeping up with later developments, I did have a few
thoughts on the design of the language.

- Setting a version at the top of Solidity source code seems like a nice idea
   and should help with making sure the language spec stays flexible enough
   for rapid iteration.  However, the lack of a fully formed dependency
   management system is a bigger flaw than a nice language version management
   system.
- The fact that all functions default to `public` visibility rather than a safer
   alternative like `internal`, `private`, or requiring an explicit visibility
   seems dangerous to me, especially given the "contract" goals of Solidity.
- The overall syntax seems to borrow from several languages but most heavily
   from javascript, java, and python.  It is nevertheless still quite clean
   and intuitive.
- The stdlib is still quite small and mostly consists of ethereum-specific
   logic and some mathematical functions.  Of course, Solidity isn't meant to
   be a general purpose programming language so it doesn't need much more.
- The lack of testing frameworks on Solidity (and the minimal testing of
   Solidity itself) really scares me.
- There seem to be multiple bindings for other languages to call Solidity
   functions.  This sounds like a nice idea, but they seem to be written as
   wrappers.  Is there benefit here from having other more popular languages
   running Ethereum operations natively instead of wrapping Solidity?