The security history of the JVM suggests that one shouldn't be optimistic there either.

counterpoint: I haven't really heard of any "javascript escaping the container" bugs in a really long time (excepting node.js-related issues)

Funny, most pwn2owns there are multiple successful escapes of any of a number of js sandboxes. I hear about it at least yearly, if not more often.

JavaScript has several mature, thoroughly scrutinized implementations. Ethereum has one brand new implementation.

To put it mildly: There will be blood.

There are actually eight different implementations at this time, although the go client has a slight majority of users according to ethstats.net

http://ethdocs.org/en/latest/ethereum-clients/index.html

There are at least two ethereum implementations, the main one and one in Rust.

JavaScript doesn't run on the JVM.

thanks for saying this, sometimes I'm like "wow" on hackernews comments, because you kind of assume people know what they're talking about but then its like not really.

I know that Javascript isn't run in the JVM, my point was that it's possible to write a virtual machine that doesn't get exploited every 5 minutes.

the JVM is a bit special because there are a large amount of escape hatches, native code and a complex trust model, which has caused a lot of the exploits you end up seeing.

But. JS was designed with this in mind, and has been tested for it for years. It's actually one of the greatest strengths of JS, but I imagine it was a lot of work (except, perhaps, maybe functional languages).

The linux kernel is and has been pretty buggy, especially by cryptographic standards.