Does Solidity really matter, though? "How's the VM" is the real question. I haven't spent more then 10 minutes looking into it, but it seemed reasonable to me. No heap and 256(?)-bit addressing seem like good ideas to keep execution complexity down.

The VM is also fucked (or, at least it was in the recent past) because it turns out that their semantics are a mess. For example, exception handling is either implicit or explicit depending on how a method is invoked!

https://eprint.iacr.org/2016/633

It does matter if the use of Solidity is being actively promoted. Sure, maybe you're smart and you'll pick safer options, but if a huge percentage of contracts are written in Solidity, it could still mean there are massive security holes everywhere.

This! ^^

Solidity code is horrible, especially after looking at concise, maintainable, provably correct code.

Ugh that's... disconcerting to say the least.

I hate immutable variables because I'm lazy but I would definitely use them as a feature in a system like this. Maybe I should reconsider using erlang or my position on immutble variables... Nope that's enough self discovery for today... Carry on.

Edit: And again erlang people can't take a joke. I'm literally making fun of myself for having an invalid bias and erlang folks take it as an attachment on the language.

It's also a commentary on how long it takes for devs to mind shift and incorporate new ideas.

There are two distinct features: immutability and single-assignment. Erlang is famous for single-assignment, and also happens to have largely immutable values, but they are not the same thing.

Immutability prevents things like in-place appending to an array, or in-place modification of a string.

Single-assigment means that the value bound to "someVariable" cannot be changed. E.g. `someVariable = new String("hello"); someVariable = new String("goodbye");` is illegal. But it still may be possible to mutate the value `someVariable.substitute("hello", "goodbye")` if the language allows mutation.

> You wouldn't trust a bank with an SQL-injection vulnerability or a hospital running on an old version of Windows either but that doesn't mean all banks and hospitals are not trustworthy

I would and do, because that's the reality of things. You're discounting the fact that if my bank has a SQL-injection exploit used against it and my account is drained, the federal government will reimburse me up to $250,000.

That type of peace of mind does not come with Ethereum; in fact it's billed as a feature.

Don't worry, they'll just do a fork and magic your money back. So much for avoiding the problems of central banking.

How often do you hear of someone loosing thousands of dollars perminantly because of a banking error? Almost never, because if a bank did not reimburse people who lost money, their reputation would be destroyed. How often do you hear of people losing thousands of dollars because of a cryptocurrency? All the time, because no one is responsible for the lost money, so no one will replace it or work extra hard to ensure it is safe. Security doesn't matter when you have a central authority dedicated to ensuring you don't loose your money, and which had been successfully doing so for decades.

What does this first sentence even mean?

I translated it as "if there is a market opportunity for there being a private, ethereum-backed federal reserve, one will emerge."

the federal government can reimburse the person I was replying to because they control and mint dollars. With Ethereum you can control and mint your own currency, I didn't want to use the word currency earlier, it is more of a digital asset or app credits.