4 ms·
I've got to admit, I'm really clueless about these things But don't we already have a universal byte code with JVM bytecode? Why did the wheel need to be rein
by geokon 9y ago
I've got to admit, I'm really clueless about these things
But don't we already have a universal byte code with JVM bytecode?
Why did the wheel need to be reinvented here? Are there fundamental issues with JVM bytecode that make it impossible/impractical to have c++/rust/LLVM compile to it?
This isn't a troll question. I'm curious what are the fundamental underlying technical issues that made WebAssembly necessary
(please be nice... c++ developer here.. so I'm really clueless about web stuff. I don't even use the JVM)
- Game_Ender 9y agoThe first upside is WebAssembly is designed to run C++ at close to native <10% overhead. The WASM team is starting with that foundation then adding features needed for GC and cross language API access (DOM). This is as opposed the Java and C# byte codes which come with a lot of assumptions baked in.
- pjmlp 9y agoCLR was designed to support C++, hence Maanged C++ and C++/CLI. Also the reason why the only major revision to the MSIL bytecodes was the support for generics.
- m1el 9y agoI'll take a stab at your question. > Are there fundamental issues with JVM bytecode that make it impossible/impractical to have c++/rust/LLVM compile to it? Lack of pointers. Lack of true structs. Different memory model. Enforced class/object model. WebAssembly has a memory model which is very close to a generic CPU. My understanding of what made WASM necessary - You don't want a GC? You don't get a GC. You want full control over your memory layout? You get a raw growable slab of memory with raw pointers.