Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

131–140 of 313 posts

Re: WebAssembly: Docker Without Containers

#131
post #115

Earlier quoted context omitted.

The problem is that WASM isn't really what you're saying. Yes, it's language agnostic. But as part of its agnosticism, it is also completely lacking in basically any runtime services . Yes, with WASI we get a POSIX-type API, but we're still lacking garbage collection, sophisticated memory management, optimized complex types, monitoring conventions etc. This is great for running existing "native" type code compiled fr…

GC semantics are highly specific and coupled to the language. Of course WASM couldn’t (and shouldn’t!) deal with that. I mostly agree with your overall point though. I’m not making the point that WASM right now (or even later) is the future of deploying backend services, however it is somewhat of a universal VM. If it’s a useful one is yet to be seen.

Yes, of course they're highly specific. And that's my point. Why would I run a GC language inside my WASM runtime, at a 2-3x or more performance overhead? Instead of just running that languages' existing runtime which has been tuned for years, and already provides its own virtual machine? What is the actual benefit?

Putting it more clearly: Most services development is done in languages that have their own virtual machine (JS/TS, Go, JVM, Python, .NET). In what world does it make sense to run that VM inside another VM?

Finally, I think the experiences over the last 20 years around .NET and the JVM should have shown there is in fact not really such a thing as a truly universal abstract VM. A well-written VM tends to be written towards supporting the language(s) it is built for.

... Not unless you're willing to throw away almost all added value, and then you start looking like WASM. And then what's your value beyond native code, running on the hypervisor and/or in a container?

(There are in fact proposals for adding GC hooks in WASM. I'd have to spend some time reading up on them to evaluate whether they address my objections.)

Re: WebAssembly: Docker Without Containers

#132
post #65

If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing. - Solomon Hykes (co-founder of Docker) https://twitter.com/solomonstre/status/1111004913222324225

This sounds incredible, as if the co-founder of Docker fails to understand the crucial value proposition of Docker (hence Docker's financial troubles, maybe). The point of Docker is the ability to take the existing Rube-Goldberg-machine configurations of software, in any and many languages (including the gluing bash scripts), and put it basically unchanged into a controlled, isolated, replicated, shippable environmen…

Solomon is no longer at Docker (hasn’t been for a while) and Docker Inc is doing extremely well financially after the split and renewed focus on developers. This Wasm release also shows they are very forward looking… I am very positive on the company and what they are doing (no affiliation other than like Scott and the team over there)

Re: WebAssembly: Docker Without Containers

#133
post #121

Earlier quoted context omitted.

The biggest missing thing in my mind is threading support. Great performance isn’t very useful if it only runs on one core.

Threading support is already implemented in some browsers and well on its way to standardization https://webassembly.org/roadmap/ Should address that concern. However there is another way of looking at performance and is in the context of serverless where typically single threaded performance is inportant, as well as cold start time etc and that’s why Wasm is popular in that scenario

“Threading support” in this sense is a bit of a misnomer, it’s really support for thread-safe memory constructs. Creating threads is left up to the runtime. On the web, this is done with WebWorkers, but on the server side I don’t think there is yet a standard way to do it supported by major runtimes.

Re: WebAssembly: Docker Without Containers

#134

What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associat…

> Fast - it can offer native-like speed via the JIT/AOT capabilities of most runtimes. No cold starts, unlike booting a VM or starting a container.

What do you mean? This bullet point had a rocket emoji! Surely you don't actually want evidence to support a rocket emoji?!?

Re: WebAssembly: Docker Without Containers

#135
post #127
post #102

Earlier quoted context omitted.

Oh shucks. Docker's value proposition is emphatically not security. If you want really good insulation, run a proper VM. Docker's value proposition is convenient. reproducible, self-contained packaging of software. It's the ability to deploy pieces of existing, battle-tested, gnarly and imperfect software next to each other, and care not about their conflicting or missing dependencies . It's more like Flatpak or AppI…

> Oh shucks. Docker's value proposition is emphatically not security. Congratulations, you have just discovered the additional value that WASM will bring to the Docker approach.

WASM is the "run a proper VM" approach mentioned in the first line.

WASM is great, but it solves a different problem.

Re: WebAssembly: Docker Without Containers

#137
post #65

If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing. - Solomon Hykes (co-founder of Docker) https://twitter.com/solomonstre/status/1111004913222324225

This sounds incredible, as if the co-founder of Docker fails to understand the crucial value proposition of Docker (hence Docker's financial troubles, maybe). The point of Docker is the ability to take the existing Rube-Goldberg-machine configurations of software, in any and many languages (including the gluing bash scripts), and put it basically unchanged into a controlled, isolated, replicated, shippable environmen…

> It's also like 2x as slow,

Do you have links to recent benchmarks? My understanding is that there were investment in bridging the gap recently.

Re: WebAssembly: Docker Without Containers

#138
post #43

Earlier quoted context omitted.

The VM part of WASM is not per se the interesting part. The really interesting part is having a VM that is not able to access the system besides what it's being explicitly allowed to by the host. This is an extremely useful security tool.

The component-model proposal makes this statement even more interesting. It will allow to set capabilities to the libraries that your Wasm module uses. For me, this is critical as in most language ecosystems, libraries gets the same permissions as the main application.

Java tried that and it is an ongoing disaster that is itself the source of security bugs.

Library boundaries are not often so rigidly clear cut as to be a security boundary, ignoring also the performance & compatibility issues that come with such a thing.

Re: WebAssembly: Docker Without Containers

#139

What I'm missing in these articles is a performance comparison. All WASMed tools I've tried were really cool proofs of concept, but the performance was always lacking at the very least. I see several languages moving towards more and more WASM but on a technical level I don't see the benefit of WASM over something like Firecracker. Docker and other sandboxes have to deal with shared kernels and all the risks associat…

[deleted]

Re: WebAssembly: Docker Without Containers

#140
post #123

Earlier quoted context omitted.

> This allows for legacy applications to be ported to a browser and directly communicate with the JS code that runs in client-side Web applications. Knowing nothing about WebAssembly, I would guess it's because JS runs on a single thread.

This is only true on the browser. Server-side JS has threads: https://nodejs.org/api/worker_threads.html

On the browser you have Web Workers and Service Workers, both run on separate threads :).

https://web.dev/workers-overview/#:~:text=Web%20workers%20an....

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

Post reply on HN