You can see an examples in Rust including the readable Wat output here:
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)
> 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.
Also the reason why the only major revision to the MSIL bytecodes was the support for generics.
Compiler IR's like WASM or LLVM IR are very laborious to type, they're intended to be produced and consumed by compilers.
You need to write very verbose code with all the type declarations, which aren't automatically propagaged, ie. `(func $foo (param $0 i32) (result i32) ...)` and `(i32.add ...)`. There's very little point in writing code like this by hand, apart from testing and debugging the compiler producing or consuming this code.
It doesn't make much sense to have this "in the cloud" outside of toy tools like this. In any kind of actual work scenario, you'd be running a compiler producing WASM on your development machine and deliver the WASM binaries over HTTP to the client machine. The whole point is to have near-native performance while reducing the compile time on the client side.
But if you want to tinker with it, knock yourself out. Here's the tool:
[0] https://cdn.rawgit.com/WebAssembly/wabt/fb986fbd/demo/wat2wa...
I think there's at least some value in these "toy tools". Would being able to tinker with WASM not help development of compilers? I place a very high value on understanding as far down the stack as you can, I don't think ignorance of every abstraction layer below the one you're working on is a very noble goal to strive for.
There are tools, even web based ones, that allow you to tinker with WASM, compile C, C++ or Rust code to WASM, print out the WAT representation, turn WAT into WASM, run the WASM blobs through JS, etc.
These tools are probably very useful for the guys developing WASM frontends and backends. E.g. sharing a piece of WASM code with other developers.
Should the average developer use them? Not really. Maybe spend an hour poking at things to get the general idea of how it works. You really don't need to understand the details of LLVM IR, SPIR-V, WASM or GCC's GIMPLE in order to use those compilers.
Is it a good idea to understand what and how are intermediate representations used in compilers but actually writing that by hand is not necessary or productive.
Almost everywhere you look in front-end web today you see a toolchain that includes the node runtime, babel or typescript as a compiler, and some kind of bundler/linker such as webpack or browserify that throws in minification/mangling in as a freebie. That doesn't even cover CSS.
JS/CSS is already a compile target with a build artifact often barely resemble the original source code. WASM is just another compile target that opens up the web as a platform for other languages.
It's funny, I'm the exact opposite. I don't like cloud apps. One day they're there, next day half their features are removed, next day they're gone. And I can't hack them to make them better fits for me when they keep changing. I want the code to run on my machine so I can do anything I want to it and have a stable environment I can rely on.
I don't put anything I care for on machines I don't own. I own many machines in the cloud. They are beautiful. Because they are all the same. They are virtual. They are cheap. I can create them with a click. There are so many vendors. If one of them would go away, it would not tamper with my ability to create new machines.
> They are virtual. They are cheap. I can create them with a click.
If they are virtual, you don't own them. You own an 'I promise really really hard' of some vendor at best.
None of which has anything at all to do with installing a fucking tool chain.
I was talking about web apps, but w.r.t. VMs... sure, at the price of your pocket though? I can run my home computer all I want and not pay for anything except the electricity and internet.
BTW you DON'T need WA if you don't have performance issues with your current web application.
As for performance: I do a lot of machine learning in the browser. So performance is something that I am interested in.
Sounds like a strange duality of criteria to me.