Nah, this use case is why Niklaus Wirth created P-Code for Pascal, and how UCSD created a full Pascal based OS that had P-Code based binaries, and some models even had a primitive JIT/AOT compiler for it.

WASM is just another reboot of bytecode based binaries that keeps poping up in multiple ways since at least 1961, when Burroughs Large Systems got released.

You're right, but even so one can still be excited it's popping up again. This time with a lot of support from various parties. And it's cool that zig goes with this solution too.

I will say that I'm mildly disappointed that there is no mention of Wirth in this article though. I guess Andrew didn't get around to read his work yet. I'd would expect him to love it; they'd probably agree on many things.

I've never really thought about wasm for the desktop (I've thought about it for server and of course browser), can you elaborate on your excitement? Is it just for this sort of bootstrapping application, or are there other benefits?

Write once, run anywhere… but this time the dream will come true!

Nearly every desktop is still x86 and just a couple years ago that was entirely true, and yet write-once-run-anywhere wasn't remotely close to true.

WASM as a result isn't changing anything here, since the assembly is very extremely not remotely close to the issue with having a portable binary.

Wasm is an opportunity for all platforms to adopt a single container format for architecture-independent binary code, and with uniforms APIs being defined on top of that; they are already standardizing a subset of POSIX. None of the bits here are really new, but the big difference this time is that it's not owned by any one of the major players (like e.g. Java and .NET were), and the design process is truly collaborative across the entire industry. This makes it politically viable.

Neither Apple nor Microsoft are supporting WASM on the desktop. Being able to run basic command line programs on top of POSIX? Sure, that'll be possible. But that's also already possible without WASM, and yet still very rarely done.

Having actually portable APIs and abstractions such that you don't need to be concerned with differences in file paths, system behaviors, system services, audio, video, windowing, input, etc...? Yeah, WASM isn't the answer to that and it's not trying to be either.

The reason Java/.NET "failed" had nothing to do with being driven by only one player and everything to do with the abstractions are so high level at that point as to be problematic. Which you either need to fully embrace, and end up with Electron, or you end up trying to reinvent WxWidgets or AWT and the clunky compromises that result where it's really just easier to build a platform-specific binary

Also both Google and Microsoft have (or currently have) their own Java bytecode runtimes. So that's not even locked up by one player, and just compare Android vs. desktop JVM to see the inevitable future of "portable WASM"

They were standardizing a subset of POSIX, until they found out why POSIX is mostly legacy nowadays.

So, now the effort is being rebooted with WASM Components.

https://github.com/WebAssembly/component-model

More like compile once and distribute one blob, run anywhere. In theory.

Write once, run anywhere is true with cross compilers and native executables without any bytecode intermediate formats. Or even things like APE executables and cosmopolitan-libc.

The hard part is finding portable libraries to actually do anything interesting. Networking, graphics, GUI, peripherals. WASM is not helping here and maybe even makes things a bit worse by introducing yet another platform to the portability matrix.

I do see the allure of using WASM for sandboxing, plugins and running untrusted code. Things where the distribution part matters.

The difference is Oracle vs. No Oracle.

You get Apple, Google and Microsoft instead (FF hardly counts).