Bytecode Alliance Preparing For Wasmtime 1.0 Releasing Later This Month

[phoronix]

Phoronix: Bytecode Alliance Preparing For Wasmtime 1.0 Releasing Later This Month

Formed back in 2019 by Intel, Mozilla, and Red Hat was the Bytecode Alliance to promote running WebAssembly (WASM) everywhere. As part of the Bytecode Alliance initiatives they have been developing Wasmtime as a WebAssembly run-time and later this month they plan to christen version 1.0...

https://www.phoronix.com/news/Wasmtime-1.0-This-Month

[-MacNuke-]

Ah yes, more runtimes. My Python, Perl, Java, .NET and JavaScript runtimes are feeling sooo lonely.

[oleid]

Ah yes, more runtimes. My Python, Perl, Java, .NET and JavaScript runtimes are feeling sooo lonely.

One runtime to rule them all. Can you use *your* runtime in the browser? With wasm this is a "yes".

[ssokolow]

Ah yes, more runtimes. My Python, Perl, Java, .NET and JavaScript runtimes are feeling sooo lonely.

All of those bake assumptions of the source language into the VM. WebAssembly is closer to being "embeddable Docker" and its bytecode is designed to be ahead-of-time compiled into machine code and then cached. (It's a successor to Google's PNaCl, which used a frozen version of LLVM's IR as its bytecode.)

[-MacNuke-]

One runtime to rule them all. Can you use *your* runtime in the browser? With wasm this is a "yes".

Sure. It's not like WASM runs inside a browser because it's so great. It runs inside a browser because browsers added support for it. Before it people just compiled stuff to JavaScript and still do.

All of those bake assumptions of the source language into the VM. WebAssembly is closer to being "embeddable Docker" and its bytecode is designed to be ahead-of-time compiled into machine code and then cached. (It's a successor to Google's PNaCl, which used a frozen version of LLVM's IR as its bytecode.)

.NET does not have language assumptions, it is designed to support multiple languages and there are many of them, it supports AOT compilation (that's the CPU killing task after .NET updates on Windows) and sure, caches the results. Java got AOT compilation with GraalVM too.

In the end it is just another runtime with different bytecode. Does not matter how the code runs. And like we already have right now a big clusterfu** when there are multiple, possible incompatible versions around. Happend with Python, happend with .NET, happend with Java. LLVM breaks its API all the time... yeah... great...

[oleid]

Sure. It's not like WASM runs inside a browser because it's so great. It runs inside a browser because browsers added support for it. Before it people just compiled stuff to JavaScript and still do.

Yes, but it turned out that JavaScript is a bad compile target. Thus, asm.js and later wasm were developed.

.NET does not have language assumptions

(...)
In the end it is just another runtime with different bytecode. Does not matter how the code runs.

The difference is that those VMs are alot more complex and even come with garbage collection, i.e. all variables are garbage collected. C.f here https://www.quora.com/How-does-Java-...e-to-WASM-code

Wasm was designed as compile target for languages like c++.

And like we already have right now a big clusterfu** when there are multiple, possible incompatible versions around. Happend with Python, happend with .NET, happend with Java. LLVM breaks its API all the time... yeah... great...

What has llvm to do with the subject aside from the name?

Anyway, we shouldn't have the problem here as wasm is properly specified and very minimalistic. Also, you're mixing up languages, standard libraries and byte code VMs.

[-MacNuke-]

Anyway, we shouldn't have the problem here as wasm is properly specified and very minimalistic. Also, you're mixing up languages, standard libraries and byte code VMs.

Sorry that I assumed that it was easy to understand what I meant.

WASM is a product of something that was a bad idea to start with. Yeah we are writing applications in our browser... oh now it is slow... now lets make JavaScript faster... yeah so now lets use JavaScript for the backend (nodejs)... oh no our poorly written software is slow again... lets make stuff like asm.js... oh now it is garbage... now lets make something like WebAssembly... oh cool lets create the backend with WebAssembly (Wasmtime)... ah shit here we go again...

It just another runtime that changes tiny bits of something that is already there. And if your Bytecode is called JVM, CLR, WASM does not really matter. Reinvention of the wheel again. I just hope it will fail horribly.

[ssokolow]

It just another runtime that changes tiny bits of something that is already there. And if your Bytecode is called JVM, CLR, WASM does not really matter. Reinvention of the wheel again. I just hope it will fail horribly.

I still dispute that. The JVM does bake some significant "reference-heavy GCed" assumptions into its bytecode that they've been trying to outgrow ever since, while WebAssembly is a successor to "make Native Client portable by distributing a frozen version of LLVM IR rather than using a patched GCC to compile to x86 machine code, minus a couple of opcodes that we don't know how to statically enforce containment on". They're very much not similar enough to say "does not really matter" if you're including them together in the same sentence.

[oleid]

WASM is a product of something that was a bad idea to start with. Yeah we are writing applications in our browser... oh now it is slow... now lets make JavaScript faster... yeah so now lets use JavaScript for the backend (nodejs)... oh no our poorly written software is slow again... lets make stuff like asm.js... oh now it is garbage... now lets make something like WebAssembly... oh cool lets create the backend with WebAssembly (Wasmtime)... ah shit here we go again...

I don't dispute that wasm was born out of strange motives. That, however, doesn't make the product bad per se.
It has use cases outside the browser world, i.e. portable sandboxed plug-ins for native applications.

It just another runtime that changes tiny bits of something that is already there. And if your Bytecode is called JVM, CLR, WASM does not really matter. Reinvention of the wheel again. I just hope it will fail horribly.

And this is where you are wrong. As described earlier, the goals of those runtimes is different. JVM and CLR are mostly similar, however, wasm is not. It is a very reduced CPU portable architecture. In essence: take riscv and remove any fancy stuff. And this architecture is very simple to implement.

Here is a wasm interpreter in a few thousand lines of C code which runs on esp32:

https://github.com/grassel/wac-esp

[-MacNuke-]

And this is where you are wrong. As described earlier, the goals of those runtimes is different. JVM and CLR are mostly similar, however, wasm is not. It is a very reduced CPU portable architecture. In essence: take riscv and remove any fancy stuff. And this architecture is very simple to implement.

Yeah, it is pretty much the same stuff Apple created years ago. And guess what... they dropped support for it.