I've yet to see a single example of WASM in the wild. How is it supposed to "replace" anything, if nobody is using it?
WASM will replace containers
71–80 of 371 posts
Re: WASM will replace containers
#72Earlier quoted context omitted.
Containers will never replace VMs either. People will be running WASM inside of containers inside of VMs.
Where did this extra VM come from?
An OCI container (what people call Docker containers) are just applications that run on a Linux kernel.
That is, you need a Linux kernel underneath for the containers to run on. More often than not, that Linux kernel is running in a virtual machine.
When you run Docker Desktop on your Windows or macOS machine, how do you think it runs that Alpine Linux container? It works because there is a virtual machine running Linux that all the Docker containers run on top of.
If you are running Linux directly on real hardware, your containers do not need a VM. Everywhere else, they do.
Re: WASM will replace containers
#73"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,…
This is what I was thinking. WASM is a good replacement for containers because it doesn't have these things.
I don't understand WASM, but I read that a big draw of WASM is it's ability to provide portability to any language. This would mean Python libraries that depend on an unpopular C library (which could be lost to time) could instead be a single WASM blob.
Assuming equivalent performance, which I understand might not be the case, is there merit to this idea? Or is there nothing new WASM provides?
Re: WASM will replace containers
#74This post is really puzzling. How do I use libraries with WASM? Lets say I wrote a nodejs app, seemingly I will need to bundle not just node_modules but also the entire nodejs runtime to make it run. Why would I do this? How does another developer make changes? If there is some way to specify what dev tools to download, what is the difference between that and docker? If you aren't doing anything complicated, docker is just a good way to set up your dev dependencies. If you are doing something complicated I doubt WASM is going to help you.
Re: WASM will replace containers
#75Suprised Nix isn't mentioned here.
Re: WASM will replace containers
#76Earlier quoted context omitted.
> … 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?”
I'm referring to a different kind of encapsulation. Dependencies, tools, version management, configurations, environment variables, etc. Even if you can fully compile your code into WASM and host it on V8 you need to ship it with configuration files, set specific environment variables and so on. Containers allow you to bundle all of that together into a single unit you can share with others.
What about WASM doesn't encapsulate dependencies? Isn't it all one WASM blob at the end of the day?
Re: WASM will replace containers
#77So dumb - Shoresy
Re: WASM will replace containers
#78When? 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…
American Express uses WebAssembly for exactly this use case:
https://thenewstack.io/amexs-faas-uses-webassembly-instead-o...
Re: WASM will replace containers
#79[deleted]
Re: WASM will replace containers
#80"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,…
You meant Java applets perhaps? Java is still write-once run-anywhere if you stick with its APIs.