101–110 of 371 posts
One benefit of being an old engineer is watching how excited people get when they rediscover something that has gone around the bend over and over again. I swear if you fuckers reinvent DCOM I will shit in your hats.
"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…
I'm always reminded of Gary Bernhardt's "the birth and death of javascript" when wasm gets discussed. While it's a bit tongue-in-cheek, I think it really drives home that it's really just another layer of abstraction that may or may not be useful for a given problem, and might not be the silver bullet that anyone is looking for. I recon that whether or not wasm will take over everything will mostly be about trade off…
That is what I was thinking of too! From 2014: https://www.destroyallsoftware.com/talks/the-birth-and-death... .
Earlier quoted context omitted.
True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime. And the nice thing about that is you can pick which environment a wasm bundle runs in. Want t…
This assumes that everyone implements the same set of APIs that work in the same way. More likely, the browser will implement some that make sense there, some browsers will implement more than others, Cloudflare workers will implement a different set, AWS Lambda will implement a different set or have some that don't work the same way... and now you need to write your WASM code to deal with these differing implementat…
I suspect you're right - unless people are careful, it'll be a jungle out there. Just like javascript is at the moment.
"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…
True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime. And the nice thing about that is you can pick which environment a wasm bundle runs in. Want t…
The problem is that in WASM-land we're heading towards WASI and WAT components, which is similar to the .NET, COM & IDL ecosystems. While this is actually really cool in terms of component and interface discovery, the downside is that it means you have to re-invent the world to work with this flavor of runtime.
Meaning... no, I can't really just output WASM from Go or Rust and it'll work, there's more to it, much more to it.
With a RISC-V userland emulator I could compile that to WASM to run normal binaries in the browser, and provide a sandboxed syscall interface (or even just pass-through the syscalls to the host, like qemu-user does when running natively). Meaning I have high compatibility with most of the Linux userland within a few weeks of development effort.
But yes, threads, forking, sockets, lots of edge cases - it's difficult to provide a minimal spoof of a Linux userland that's convincing enough that you can do interesting enough things, but surprisingly it's not too difficult - and with that you get Go, Rust, Zig, C++, C, D etc. and all the native tooling that you'd expect (e.g. it's quite easy to write a gdbserver compatible interface, but ... you usually don't need it, as you can just run & debug locally then cross-compile).
WASM does not run on real hardware. At best, WASM can be considered a virtual machine (in the way that the JVM and the .NET CLR are virtual machines). I guess we can call that a "runtime". Containers package applications that run directly on real hardware (well, directly on a real kernel that is running on real hardware). There is no runtime. I am talking OCI containers here (Docker and Kubernetes). At least they can…
> WASM does not magically eliminate dependencies or the differences between environments (not even the difference between V8 implementations).
Not by itself, and not currently, but I don't find it too much of a leap of faith to assume that that'll be standardized before too long.
When? We’ve been talking about wasm for years. When are we actually getting this future? It’s been 8 years since wasm 1.0, and still we don’t have a stable, easy to use toolchain. Rust has maybe the best support and I still can’t get a basic async application with tokio to work on wasm. To put it into context, Rust was released in 2012. 8 years later it was stable, had a solid toolchain and plenty of people using it…
Around the same time Linux is ready for the desktop.
Earlier quoted context omitted.
True, but I suspect it'll be a lot easier to virtualise all those APIs through WASM than it is for a regular native binary. I mean, half the point of docker is that all syscalls are routed into an LXD container with its own filesystem and network. It should be pretty easy to do the same thing in userland with a wasm runtime. And the nice thing about that is you can pick which environment a wasm bundle runs in. Want t…
This assumes that everyone implements the same set of APIs that work in the same way. More likely, the browser will implement some that make sense there, some browsers will implement more than others, Cloudflare workers will implement a different set, AWS Lambda will implement a different set or have some that don't work the same way... and now you need to write your WASM code to deal with these differing implementat…
Things are going to change a little bit with the introduction of Preview3 (the flagship feature there is async without function coloring), but you can look at the core interfaces:
https://github.com/WebAssembly/WASI/tree/main/wasip2
This is what people are building on, in the upstream, and in the bytecode alliance
You're absolutely right about embeddings being varied, but the standard existing enforces the expectations around a core set of these, and then the carving out of embeddings to support different use cases is a welcome and intended consequence.
WASI started as closer to POSIX now, but there is a spectacular opportunity to not repeat some mistakes of the past, so some of those opportunities are taken where they make sense/won't cause too much disruption to people building in support.
We’re still using COBOL mainframes in 2025 in places so I’m sure whatever is the next trend in computing will be great, but I’m sure we’ll still be using k8s (and COBOL) in 2125.
> but I’m sure we’ll still be using k8s (and COBOL) in 2125. If you want a vision of the future, imagine a bare metal hypervisor hosting Linux hosting K8S hosting V8 hosting a WASM-based IBM mainframe emulator running COBOL.
"The main thing holding back wider adoption is a lack of system interfaces. File access, networking, etc. But it's just a matter of time before these features get integrated." But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. That's what killed the Java write-once, run-anywhere promise. Maybe put the whole thing into a container? Oops,…
ActiveX had this sorted out 25 years ago. Code signing with different levels available for access outside the sandbox controllable by the user.