short short answer that is deliberately terse: the hopper language, once a wee bit more mature, will be a dependently type language with linear types (to model first class ownership) and a few other facilities for modelling interaction and authorization along with logical soundness as hard goals. Imagine if agda had a linear logical baby that was designed to be easily embeddable in a host application and/or standalone, and also designed with RTS and compiler improvements from the the outset. plus a few other tbd goodies to make it nice to use.

the ethereum vm doesn't have any notion of ownership or authorization built in, those are provided whole cloth by application level authors (have fun doing that correctly for every app!). I could opine more than that, but I think thats the most i should say about the quality of the stack vm specification or its semantics :)

> I think thats the most i should say about the quality of the stack vm specification or its semantics

As someone who spends a lot of time with Ethereum, I'd love to hear more. Honestly, I almost never deal with the stack level language (only the higher level Solidity). Isn't it possible to write whatever language you like on top of that stack based language?

There is a proposal[1] to upgrade the current EVM to a WebAssembly based VM. Since webAssembly has a llvm backend, any language with a llvm compiler (which is most of them) could be used to write contract code.

1. https://github.com/ethereum/EIPs/issues/48

This is a vast oversimplification of the problem. LLVM is a compiler IR; nothing more. It is not portable (you cannot generate IR for one target and have it work for another target) and it does not trivially map to the semantics of most languages beyond C.

A programming language is a combination of many components; assembly optimization and target code generation is just one important part of a much larger picture.

I'm only responding critically because I've seen this trope that LLVM is some sort of universal programming language target way too often now. It misleads people into underestimating the scope of the actual problem. LLVM is not a panacea.

If you really want to make your platform programmable from any programming language, invest time into a well designed C API. Your users will thank you.

This is addressed in the linked issue.[1] Your criticism is the reason why (a subset of) WebAssembly is used, not LLVM IR.

1. https://github.com/ethereum/EIPs/issues/48#issuecomment-1690...

theres also the issue that committing to too low level an IR really makes it hard to do nice optimizations in a portable way! :'(

Should also point out that Juno can run EVM, via Masala, which is our stand-alone EVM interpreter. (https://github.com/slpopejoy/masala)

One thing EVM gets right is being a deterministic state machine -- giving rise to the possibility of "diffed" outputs, which is a feature of Hopper. This makes it amenable to offering a sidelong key-value store that is 100% verifiable, offering fast restarts and (dirty) reads.

Hopper's main goal is to reduce the surface area of computation, in order to focus on the problem of mass-conservation and transactionality. In EVM you have to code all of this stuff yourself. As we've seen, this requires a LOT of code.

EVM also bundles in a notion of accounts, which Juno does not.