Hacker News Reader

Comment by hexhex | Hacker News Reader

I didn't have high expectations for Solidity considering the recent vulnerabilities, but even these were disappointed. If some guy writes this kind of code at home, alright, but this as the alleged foundation for our future financial system? Frightening.

Just one example: "Our function EndLottery() must be only accessible by the owner of the lottery." [0]

function EndLottery() public { if (msg.sender == owner) { ... } }

What about code guards? Not to speak of decent typing, etc. etc.

[0] https://ethereumdev.io/managing-multiple-users-a-simple-lott...

View on HN

I understand the eth VM is pretty limited and limiting, but Solidity is just sad, it's like somebody saw Javascript and thought "ok that's a pretty terrible basis for writing contracts, but surely we can make it even worse?"

And then they succeeded at failing.

Can't remember where I read it, but someone put it best during the DAO fiasco last year when they wrote "Imagine Javascript but your bank account accessible through the Document Object Model."

Even that's only scratching the surface of how awful Solidity is. An example of minor security detail straight from the documentation is this:

    for(var i=0; i<arr.length; ++i) {

Solidity is a "statically typed language" with "type inference". In most of these, you'd expect i to be typed as whatever the type of arr.length is, but Solidity does not care, it sees `var i = 0`, 0 fits into a uint8 so a uint8 i is, it'll get promoted during the comparison and if arr has more than 255 elements it'll overflow and the loop is infinite.

Many issues with Solidity as a contract language were pointed out in a previous HN thread after the Parity multisig-incident: https://news.ycombinator.com/item?id=14810008

I'll do you one better, vulnerabilities directly associated with the dynamism of Solidity were predicted on LtU in 2014:

http://lambda-the-ultimate.org/node/5003

Have you read next article? https://ethereumdev.io/better-readability-with-modifiers/

You are right, they solved the particular problem I highlighted with Modifiers.

But the main question remains: Why don't they utilize the progess we made in decades of research for better programming languages?

The argument that Solidity should be useable by the average programmer doesn't hold, in fact, typing makes programming easier since it clarifies data structures that are implicit in languages like JS.

PL people often direct their "it should be functional and use strong typing" critique at the EVM rather than Solidity. Solidity is just one HLL (higher level language) that compiles to EVM bytecode.

A lot of the limitations of Solidity are due to constraints of the EVM, but the EVM is evolving. For instance, the next planned hard fork will enable the EVM to pass dynamically sized data (e.g. solidity arrays or strings) between call stacks. Previously arrays had to be fixed-size, so you'd have to define a fixed maximum size, then always return data of that size (usually a lot of empty elements). This feature, like many others, is somewhat challenging to design because every execution step of the EVM must be metered by a "gas fee"; the first version of the EVM kept it simple by only allowing return data to be a fixed size. See these issues for background https://github.com/ethereum/solidity/issues/164 https://github.com/ethereum/EIPs/pull/211

Also, the longer-term proposal is to adopt WebAssembly for EVM 2.0: https://github.com/ewasm/design. Then users can write contract code using any language with an llvm compiler (rust, ocaml, etc.).

I agree about typing but unfortunately I'm not a core dev. The compiler does a good job at warnings thought...

Reply on news.ycombinator.com