Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

281–290 of 313 posts

Re: WebAssembly: Docker Without Containers

#281

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…

> but the performance was always lacking at the very least.

This is an easy engineering problem which will be solved when there's enough motivation and engineers working on it.

Increasing adoption is more of a business problem though, and it is unclear if performance is the bottleneck here.

If you have a wasm product that has to be as fast as native code, the solution is to find compiler engineers (or a company that specializes in this) who will solve this for your situation.

Re: WebAssembly: Docker Without Containers

#282
post #281

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…

> but the performance was always lacking at the very least. This is an easy engineering problem which will be solved when there's enough motivation and engineers working on it. Increasing adoption is more of a business problem though, and it is unclear if performance is the bottleneck here. If you have a wasm product that has to be as fast as native code, the solution is to find compiler engineers (or a company that…

Bro we are hearing about this sufficient smarts compiler for some decades now.

Re: WebAssembly: Docker Without Containers

#283
post #230

Earlier quoted context omitted.

That's how WASI is designed. You need to specifically mount a specific folder so it can be accessed by the module. The sockets support is not ready yet, that's the reason there's no specific limitation around networking. For me, the most interesting part is the component-model. It's still a proposal, but it will allow developers to specify the permissions for other modules (libraries) a main Wasm module may use. With…

Why can't this be done with native code and sandboxing? Native code in a sandbox doesn't require a VM, and there is a big perf cost for wasm. Is it just for one extra layer of security?

You have to remember that WASM comes from web browsers. It is meant to be transferred across the web and run in a the browser on the target computer. It isn't very practical to compile everything to every architecture/os combination and serve the correct implementation.

Re: WebAssembly: Docker Without Containers

#284
post #281

Earlier quoted context omitted.

> but the performance was always lacking at the very least. This is an easy engineering problem which will be solved when there's enough motivation and engineers working on it. Increasing adoption is more of a business problem though, and it is unclear if performance is the bottleneck here. If you have a wasm product that has to be as fast as native code, the solution is to find compiler engineers (or a company that…

Bro we are hearing about this sufficient smarts compiler for some decades now.

You are right when it comes to general purpose compilers.

You can do a lot more if you just want to speed up your codebase.

All the big tech companies employ multiple hundred compiler engineers each for this purpose.

Re: WebAssembly: Docker Without Containers

#285
post #230

Earlier quoted context omitted.

Why can't this be done with native code and sandboxing? Native code in a sandbox doesn't require a VM, and there is a big perf cost for wasm. Is it just for one extra layer of security?

You have to remember that WASM comes from web browsers. It is meant to be transferred across the web and run in a the browser on the target computer. It isn't very practical to compile everything to every architecture/os combination and serve the correct implementation.

Yeah but that's not the context of this use. Why are they taking something made for browsers (where architecture neutrality is important) and using it for sandboxing, instead of faster sandboxed (not VMed) native?

Re: WebAssembly: Docker Without Containers

#286
post #285

Earlier quoted context omitted.

You have to remember that WASM comes from web browsers. It is meant to be transferred across the web and run in a the browser on the target computer. It isn't very practical to compile everything to every architecture/os combination and serve the correct implementation.

Yeah but that's not the context of this use. Why are they taking something made for browsers (where architecture neutrality is important) and using it for sandboxing, instead of faster sandboxed (not VMed) native?

They are doing it for the same reason people keep ripping JS engines out of browsers: there has been so much work done to make them fast, harden the sandbox, and port them to different platforms. It's free real estate.

Re: WebAssembly: Docker Without Containers

#287
post #263

Is there some page or document that explains how this actually works from the point of view of a traditional container / UNIX process worldview? Like, have the WASM folks implemented an emulation layer for Linux system calls? For libc? POSIX? Or maybe you need to modify your traditional programs so that they use WASM APIs instead? Just very confused at the moment :) I get the core idea of compiling other languages to…

I believe this is what WASI is https://github.com/bytecodealliance/wasmtime/blob/main/docs/...

Aha! Thanks. :)

So it sounds like it's a new capability-based syscall interface, but they've ported big chunks of libc (specifically musl) to that interface so that a lot of things work.

Re: WebAssembly: Docker Without Containers

#288
post #5

Earlier quoted context omitted.

Well, those that act like WebAssembly is reinvinting the world kind of do. And applications get tied to the WebAssembly ecosystem, it is also a single one.

What's wrong with a "JVM but for everyone who isn't a Java developer"? If the model works, why shouldn't there be competitors and wide spread adoption?

"JVM but for everyone who isn't a Java developer" would be good but WebAssembly isn't really suited for it. It works for some static native-code targeting languges (C, C++, Rust, Zig, etc) but doesn't work well for languages that most application developers use (.NET languages, TypeScript/JavaScript, Python, Clojure, Java, Ruby, etc).

Re: WebAssembly: Docker Without Containers

#289

Earlier quoted context omitted.

What's wrong with a "JVM but for everyone who isn't a Java developer"? If the model works, why shouldn't there be competitors and wide spread adoption?

"JVM but for everyone who isn't a Java developer" would be good but WebAssembly isn't really suited for it. It works for some static native-code targeting languges (C, C++, Rust, Zig, etc) but doesn't work well for languages that most application developers use (.NET languages, TypeScript/JavaScript, Python, Clojure, Java, Ruby, etc).

> "JVM but for everyone who isn't a Java developer" would be good but WebAssembly isn't really suited for it. It works for some static native-code targeting languges (C, C++, Rust, Zig, etc) but doesn't work well for languages that most application developers use (.NET languages, TypeScript/JavaScript, Python, Clojure, Java, Ruby, etc)

.NET/Java/Clojure, maybe not. Ruby and Python work via an interpeter for the platform, just like they do on JVM/.Net, except that, unlike JVM/.NET, in both cases they can use the normal C-based interpreter, compiled for WASM.

Re: WebAssembly: Docker Without Containers

#290

Earlier quoted context omitted.

"JVM but for everyone who isn't a Java developer" would be good but WebAssembly isn't really suited for it. It works for some static native-code targeting languges (C, C++, Rust, Zig, etc) but doesn't work well for languages that most application developers use (.NET languages, TypeScript/JavaScript, Python, Clojure, Java, Ruby, etc).

> "JVM but for everyone who isn't a Java developer" would be good but WebAssembly isn't really suited for it. It works for some static native-code targeting languges (C, C++, Rust, Zig, etc) but doesn't work well for languages that most application developers use (.NET languages, TypeScript/JavaScript, Python, Clojure, Java, Ruby, etc) .NET/Java/Clojure, maybe not. Ruby and Python work via an interpeter for the platf…

You can do it, but it remains to be seen if we get a lot of use cases where there are more positive than negative tradeoffs from targeting a VM implementation to WebAssembly and then running a VM inside a VM that way. I guess eg Python could be useful in cases where you want to use it as a glue language between WebAssembly components...
Post reply on HN