Yes, it's crazy, but it's also happening.
Solidity doesn't appeal to me because its goal seems to be on-boarding JavaScript programmers. But new languages that compile to EVM can be easier to use "safely" and you will see several of these in the next few years.
I'm really excited that a project to embed Turing-complete behavior in a blockchain has actually taken off. It's completely insane from one perspective, but completely awesome from another.
The interesting question is whether a language can be design which allows the important domain-relevant requirements to written down in an understandable way and also proved rigorously.
So far neither lawyers nor programmers have done a very good job of this in their respective field. Watching people trying to do it in both fields simultaneously sounds like popcorn time to me.
And huge swaths of activity where programmers have laid out clear deterministic expectations.
If you're saying lawyers have failed to specify the legal ramifications of All Possible Activity then... Sure. So? Even if Ethereum only works for one single narrowly defined contract, it could be immensely useful.
The question for me isn't "where could it fall short" but "where might it measure up?"
A web app might not touch real money, but a leak can still have real money consequences for the users.
Short of auditing the Solidity contract code myself, there's nothing I can do to protect myself from the hacks themselves because the very mechanism by which money is transferred is riddled with bugs.
This is mostly just semantics anyway - I'm just trying to establish that writing money-transfer software in a poorly designed language is, one way or another, worse than writing a web app in one.
- vulnerabilities can be used to attack users directly or through social engineering
- (rare today, but definitely a problem with C++ web apps) you can break through a hole in the app and pwn the whole server
A poorly written smart contract that handles real money, on the other hand...