I tried to answer this above[0]. Instead of trying to explain it again, I’d encourage you to give it a try[1], and if after going through the 5-minute tutorial you still don’t get the point then a) maybe we messed up (and I’ll be sorry for having wasted your time!) or b) maybe it’s not for you (and I’ll also be sorry I wasted your time). It took me a while to wrap my head around this Docker+Wasm thing too when I firs…
Your second link answered my questions well, thanks.
Why not run that go/rust/etc code natively on the machine though? Is there extra sandboxing, network/filesystem virtualization or anything gained by compiling to and running in a WASM environment?
One benefit of using wasm is architecture-agnostic binary. Right now you can't run x86 binary on ARM or vice-versa. So basically you need to build your containers twice if you have macbook people and x86 servers. And technically those are different images, so there's chance that you'll hit some non-trivial difference. With wasm everything could be simpler.
Building and deploying is most often the job of the pipeline so the arm debug build from the developer desktop won't be run on the X86 server.
So the distillation is something like this? "Docker images can now be deployed directly to the WASM runtime! This means your AWS Lambdas, Cloudflare Workers, etc. will boot faster and cost less..." When you rehash what Docker already does, it's watering down the messaging. Even adding "AWS announced support for containers on Lambda last year" in the last reply made the voice in my head ask again, "What's different ab…
That’s not quite right. You can’t take an existing container app and just "export" it as Wasm. (Technically you might, but it would require a pretty big re-architecture and re-write, as Wasm doesn’t support garbage collection or multithreading at the moment. It also requires you use a language that can be compiled to Wasm, which can be limiting. Due to this, Wasm — at this stage — is probably best fitted to functions…
I think what's missing is why you'd want to do that.
If I have a rust app on a scratch image, why would I want to turn it into a wasm container?
My assumption is because wasm can run on multiple platforms (x86 and arm) so one image supports both, is that correct? Are there other reasons not as obvious?
That’s not quite right. You can’t take an existing container app and just "export" it as Wasm. (Technically you might, but it would require a pretty big re-architecture and re-write, as Wasm doesn’t support garbage collection or multithreading at the moment. It also requires you use a language that can be compiled to Wasm, which can be limiting. Due to this, Wasm — at this stage — is probably best fitted to functions…
I think what's missing is why you'd want to do that. If I have a rust app on a scratch image, why would I want to turn it into a wasm container? My assumption is because wasm can run on multiple platforms (x86 and arm) so one image supports both, is that correct? Are there other reasons not as obvious?
Assuming you had code that somehow could either be packaged as a linux container, or as a Wasm binary, then the advantage of the latter would be that yes Wasm supports multiple CPU architectures out of the box, it also consumes less resources (memory, etc.), will usually have faster start times, and the Wasm security sandboxing is stronger.
I think what's missing is why you'd want to do that. If I have a rust app on a scratch image, why would I want to turn it into a wasm container? My assumption is because wasm can run on multiple platforms (x86 and arm) so one image supports both, is that correct? Are there other reasons not as obvious?
Assuming you had code that somehow could either be packaged as a linux container, or as a Wasm binary, then the advantage of the latter would be that yes Wasm supports multiple CPU architectures out of the box, it also consumes less resources (memory, etc.), will usually have faster start times, and the Wasm security sandboxing is stronger.
> it also consumes less resources (memory, etc.)
Really? I would not have expected that. Is that just under the assumption that most apps have an underlying OS (like alpine) and aren't on a scratch container?
I think the # of people losing a lot of of battery to this is miniscule, especially since the OSX x86 emulation is pretty fast. A bigger peeve is that there is no general reasonably fast cross build ability, to eg build, test and debug ARM images (for runnign on ARM servers) on x86 Linux or Windows etc.
There's no OSX x86 emulation. There's Rosetta emulation and qemu emulation. Rosetta emulation is quite fast. But docker does not use it. At least for now. qemu emulation is extraordinarily slow and basically unusable for anything but the simplest code.
That’s pretty much the point of WASM, isn’t it? V8 is a billion dollar investment in running as best as possible a language that is very, very difficult to run performantly. WASM instead opens up options to run well languages that are much easier to run performantly.
Definitely it is, and it does open doors for this, I'm just curious if running say, a JavaScript or Python interpreter on top of WASM would be more performant than V8, given that there could be two layers of VMs, ie the WASM VM and the JS/Python VM running on it. I'd hope that they'd be comparable in performance, especially when it comes to doing client-side web app things in languages other than JavaScript.
Currently JIT in wasm is incomplete. That is a wasm program cannot modify itself (it would need to create new modules and ask the host to load them with a shared memory)
So compiling JS to wasm would probably be limited to the performance of interpreting JS on native
This is great. We’ve been chatting with Docker for a little bit (I’m Syrus, from Wasmer) and it’s great to see that they are making progress on improving the developer experience around WebAssembly. However, I see Docker (and thus, Kubernetes) is as technologies of the past (I don’t intend to start any flamewar, I really believe this by heart). Metal compute (Web 1.0) lead to VMs which then lead to Containers (Web 2.…
If the containers become old tech and docker poses itself as the new "wasm delivery and registry platform" it is a net win for them.
The only risk is if splitting the effort damages them in both fields...