Live data from Hacker News

WASM will replace containers

creston.blog

11–20 of 371 posts

Re: WASM will replace containers

#11
lol I initially thought dylibso was the author, I was mistaken. That being said - WASM has been steadily improving over time, yet it hasn't quite achieved mainstream adoption.

I'm curious what's holding it back?

It seems like despite its technical advancements, WASM hasn't captured the public's interest in the same way some other technologies have. Perhaps it's a lack of easily accessible learning resources, or maybe the benefits haven't been clearly articulated to a broader audience. There's also the possibility that developers haven't fully embraced WASM due to existing toolchains and workflows.

[1] https://github.com/dylibso

Re: WASM will replace containers

#12
post #3

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.

Re: WASM will replace containers

#13
"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, looks like the container wasn't replaced after all (though perhaps it could be simplified).

Re: WASM will replace containers

#14
post #2

It would be so great if WASM gives us the paradise that Java promised thirty years ago. Being able to get fast, "write once, run anywhere" would be awesome. I wonder if someone could make a decent cross-platform GUI toolkit to save us from the horribly slow Electron-hell we've carved out for ourselves.

We could name it the Abstract Window Toolkit and it would render the same on every platform. But then, someone would get butthurt about it having a "distinct look" and decide to make the Standard Widget Toolkit that uses native bindings. Fantastic that it stops that distinct look, with the small asterisk that you now have to ship .dll/.so/.dylib shims in your "cross platform" app

I'm no wasm expert, but I find it just fantastically unlikely that they're going to beat the decades of research that have gone into the JIT in the JVM anytime soon. But, I guess if the objective is just "run this bytecode in every browser on Earth," that ship has sailed and I will look forward to more copies of node infiltrating my machines

Re: WASM will replace containers

#15

Containers have two goals: reproducibility/portability, and encapsulation. WASM could replace the reproducibility but it can't replace the encapsulation. > My money is on WebAssembly (WASM) to replace containers. It already has in some places. WebAssembly is a true write-once-run-anywhere experience. (Anywhere that can spin up a V8 engine, which is a lot of places these days.) Luckily a container is a place that can…

> … it can't replace the encapsulation.

Can you explain your thoughts here? WebAssembly is sandboxed and effort must be expended to provide a mechanism for getting data through that boundary. How does that differ from “encapsulation?”

Re: WASM will replace containers

#16
"In the year 2030, no one will remember Kubernetes."

I feel like this prolog missed an important point. Kubernetes abstracts data centers: networking, storage, workload, policy. Containers implement workloads. They're at different layers.

And back to the article's point: WASM may well replace containerized workloads, indeed there are already WASM node runtimes for Kubernetes. Something else may well replace Kubernetes in five years, but it won't be something at the workload layer.

Re: WASM will replace containers

#17
The author has not seemingly considered the vastly different networking in wasm. You don’t have networking. There is an entirely different utility in these environments, containers are meant to host applications, wasm is an application. Don’t even get me started on disk access, env handling, etc. wasi is great, for the places it does well. It is not a replacement for writing a pure golang/rust/c/julia app and running it in a container, it doesn’t have the facilities for that task.
Post reply on HN