Live data from Hacker News

WASM will replace containers

creston.blog

81–90 of 371 posts

Re: WASM will replace containers

#81
post #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 Kubernete…

I came here to say this. Kubernetes is an ecosystem that represents a better way of running production workloads at scale for many orgs. People already use Kubernetes for VMs, and various different container runtimes are used by different cloud providers. If WASM does replace containers (unclear to me), Kubernetes would just support WASM, and stay largely similar.

Re: WASM will replace containers

#82

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....

Re: WASM will replace containers

#83
As PlatformOps (formerly DevOps (formerly SRE (formerly Ops))), either this was hilarious satire or ChatGPT Ketamine trip. I'm not sure.

> In the year 2030, no one will remember Kubernetes.

So what's going to handle out rolling out new versions of your WASM, setting up whatever Reverse Proxy you pick and other stuff involved getting. A bunch of scripts you wrote to do this for you? https://www.macchaffee.com/blog/2024/you-have-built-a-kubern...

> The promise of DevOps has been eroded by complicated tooling and tight coupling of program-container-linux. In my experience, developers want to write code and ship features to hit their quarterly goals.

Here is why we ended up here: In my experience, developers want to write code and ship features to hit their quarterly goals.

Sure, and my angry PlatformOps (formerly DevOps (formerly SRE (formerly Ops))) is stuck picking up the pieces because we are getting crap while we desperately paging you because we have no clue what "duplicate street key" in your logs mean. On top of that, InfoSec dropped us 10 tickets about code level library vulnerabilities in your docker container but all the Developer's Managers got together to convince them it was our problem somehow.

So we are forced to write this bundle of terribly written Ops type software in attempt to keep this train on the tracks while you strap rockets to cafe car.

WASM replacing containers is just a solution looking for a problem. Containers solved a problem of "How do we run two different versions of PHP on a single server without them colliding." Most of the containers problem is higher level DevOps problems that we haven't been able to solve and WASM isn't going to change that. I deal with a team that writes 100% Golang so their code is like WASM as it's ship binary and done. Yea, they begged for Kubernetes because it works a ton better then custom Ansible they wrote to keep these VMs/Load Balancer in sync.

Re: WASM will replace containers

#84
post #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 jus…

> 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

Probably not, but that's sort of orthogonal to my point.

Java started as "write once run anywhere", but it has almost become the opposite of that: "write once, run it on your specific server".

"Portability" is not nearly the same concern with Java as it was thirty years ago; I don't have direct numbers on this, but I would guess that a vast majority of Java code written in 2025 is either running on a server or running an Android app, neither of which are nearly as "portable" what was kind of promised in the 90's, at least not on the desktop.

Re: WASM will replace containers

#85
WASM might replace processes, but the idea that people will take the stuff they can't manage to put in a native process, and somehow manage to cram it into WASM... ridiculous.

There's not even a single argument in there to support the clickbait title. We have containers, but "containers are annoying". WASM won't be annoying? Pray tell, how do you surmise that?

Docker too complicated? Build times too long? You believe WASM tools will be simpler and faster... why?

Re: WASM will replace containers

#86
I actually tried doing this a couple weeks ago. Rust on Cloudflare Workers. It didn't go well -- compiling to wasm disables a lot of Rust features, to the point where it just didn't make sense anymore. I gave up after trying to get some crypto stuff working. I eventually switched to using raw JS because Cloudflare Workers exposes the Web Crypto API, but next time I want to run Rust serverlessly, I'm just going to put it on Lambda, compiled to a regular binary.

Re: WASM will replace containers

#87

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…

Emscripten seems pretty stable and easy to use to me?

Re: WASM will replace containers

#88
Right. Moore's law has made too much progress. We must claw back some slowness! Let's take code that could run securely at full speed and run it in emulation at half the speed instead. That'll keep those menacing hardware performance improvements at bay a little longer.

Re: WASM will replace containers

#89
post #57
post #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,…

>But then you've got to figure out and prevent all the security holes that can be introduced by adding file access, networking, etc. So an operating system?

Yes. Wasm does to my knowledge not have an answer for this, even if some projects patch in their bridge logics. Networking and file systems, and the permission model, is "the rest of the fucking owl". Linux isn't standardized, but at least it's Linux. Without consensus on the fundamental APIs I don't see how we can get to a platform agnostic experience. Even an https call isn't simple: you need TCP and you need to pull root certs from the env, at the very least. Where's the API for that?

I hope for a much more near term bright future for WASM: language interop. The lowest common denominator today is C, and doing FFI manually is stone age. If you can leverage WASM for the FFI boundary, perhaps we can build cross language applications that can enjoy the strengths of all libraries, not just those outside of our language silos.

Re: WASM will replace containers

#90
> In the year 2030, no one will remember Kubernetes.

That's 5 years from now.

Which is a pretty good time frame for getting enterprisey things on to kubernetes.

And maybe a bit short for getting vendors to add a new sandboxed VM type to their supported platforms.

Post reply on HN