Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebAssembly: Docker Without Containers

wasmlabs.dev

Post reply on HN
Print view View original

111–120 of 313 posts

Re: WebAssembly: Docker Without Containers

#111

Post by talkingtab »

nine_k wrote: post #65
tony-allan wrote: post #2

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…

Good point.

I just wonder how many founders and co-founder fail to understand the crucial value proposition of their business. I suspect one attribute of successful start ups is that over time they come to understand that aspect. And perhaps when we hear of startups "pivoting" that is not the result of a though process but instead a forehead slapping "why didn't I see that?" moment.

Re: WebAssembly: Docker Without Containers

#112

Post by orf »

mike_hearn wrote: post #105
orf wrote: post #95

Earlier quoted context omitted.

It depends on the program being compiled, but yes you can. You can run Postgres using WASM in two different ways[1][2]. That’s a non-trivial codebase. 1. https://www.crunchydata.com/blog/learn-postgres-at-the-playg... 2. https://supabase.com/blog/postgres-wasm

That works by compiling some sort of Linux VM into WASM as well, which isn't arbitrary programs (that would have to include Windows and macOS programs too).

I feel like you’re nitpicking and ignoring the actual argument you originally made?

You can compile arbitrary programs to WASM, like you can compile arbitrary programs to x86 or ARM. It’s effectively a CPU target. You can take the whole of Python and SQLite, compile them to WASM and run a web framework on top of that via WASM in the browser[1].

If those programs utilise specific os-level behaviour that can’t be shimmed, or explicitly throw an error when being compiled to WASM then of course they won’t work without modifications.

Meanwhile, the JVM is not anything like a CPU target. It’s a very high-level VM designed for a particular type of gc’d and jitted language.

1. https://simonwillison.net/2022/May/4/datasette-lite/

Re: WebAssembly: Docker Without Containers

#113

Post by cmrdporcupine »

orf wrote: post #4
pjmlp wrote: post #3

Earlier quoted context omitted.

Indeed, he just had to make use of JVM or CLR based application servers instead. That is what this whole trend is all about, replicating application servers with WASM. Every time I need to dive into k8s stuff, I can only think "this was so much easier when configuring WebSphere and EAR deployments".

Nobody is saying WebSpehere didn’t have benefits and configuring it likely was easier than full-blown Kubernetes. But the similarities are shallow at best and tied you into a single VM. Saying “this whole trend is all about replicating application servers with WASM” makes it sound derivative. I mean, yes, but only yes in the same way “cloud computing is just replicating large remote shared mainframes”.

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 from C/C++/Rust but its profoundly unsuited to the kind of development that most application or service developers do, which is in higher level languages with automatic memory management, monitoring / profiling services, etc. All of which either have to be re-invented in the WASM world, or run inside the WASM container at 2x or more the runtime/energy cost. And for what benefit?

It's one thing to get a game engine running in a web browser. Neat hack / potentially decent way to ship a client.

It's another thing to try to repackage existing working, relatively well engineered, server runtime systems inside it for almost no benefit at all.

TDLR: WASM is not a universal VM appropriate for server apps. It is a solution for shipping a certain kind of application in a certain circumstance. There are other, better, solutions for "containerizing" services.

Finally, after 25 years in this industry, the world I want to head to is higher level, where things are managed declaratively with explicit, visible, well described rules and relations and logic. WASM seems to me to push the other direction. Black boxes of fairly low-level code, each reinventing its own runtime wheel and with almost no visibility from the administration side of what's happening in there. I find that kind of sad.

Re: WebAssembly: Docker Without Containers

#114

Post by rowls66 »

_boffin_ wrote: post #104
pjmlp wrote: post #75

Earlier quoted context omitted.

- Schema validation - IDE code completion - Can be machine generated/updated via the GUI management administration and graphical tooling on IDEs Good luck doing that with YAML.

I’m failing to see why you can’t do that with yaml. Please enlighten me.

You can do it with YAML, and when you do, you end up with something big and complicated like XML became.

Re: WebAssembly: Docker Without Containers

#115

Post by orf »

cmrdporcupine wrote: post #113
orf wrote: post #4

Earlier quoted context omitted.

Nobody is saying WebSpehere didn’t have benefits and configuring it likely was easier than full-blown Kubernetes. But the similarities are shallow at best and tied you into a single VM. Saying “this whole trend is all about replicating application servers with WASM” makes it sound derivative. I mean, yes, but only yes in the same way “cloud computing is just replicating large remote shared mainframes”.

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.

Re: WebAssembly: Docker Without Containers

#116

Post by lolinder »

rowls66 wrote: post #114
_boffin_ wrote: post #104

Earlier quoted context omitted.

I’m failing to see why you can’t do that with yaml. Please enlighten me.

You can do it with YAML, and when you do, you end up with something big and complicated like XML became.

You should really try the k8s plugin in intellij. It does all of the things OP asked for without adding a single extra line of complexity to the yaml file.

Re: WebAssembly: Docker Without Containers

#117

Post by jeroenhd »

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 associated with that, but leveraging virtual machines instead solves that issue. There are already proof of concept implementations to replace Docker with VMs as a virtualisation layer, so I wonder if it wouldn't be better to invest time in getting those wrappers completely up and running rather than coming up with essentially "Java but we also emulate the OS".

Until WASM advocates start including benchmarks in their blogs, I'll keep watching this stuff from a distance.

Re: WebAssembly: Docker Without Containers

#118

Post by whimsicalism »

mike_hearn wrote: post #108
orf wrote: post #96

Earlier quoted context omitted.

You can’t run Postgres on the JVM. WASM is pretty different to the JVM. The JVM deals with a lot of higher level constructs like objects, constructors, virtual methods, the GC etc. Which is fine if the language you’re hosting works in that way. WASM is more like assembly - the raw intrinsics used by a hypothetical WASM CPU. So you can compile a lot more stuff to it, because it’s a more natural target than a much, muc…

Although that's true (ish... you can run WASM on the JVM now, and also LLVM bitcode), that takes you into the realm of why you'd want to. On the browser side, you could maybe make a ChromeOS style argument of just wanting to run everything in a browser no matter what, it's nice for it to be sandboxed etc. But if you look at what your Postgres is doing it's sort of a Linux VM, and you can run those already at full spe…

LLVM on the JVM is news to me, have a link?

Re: WebAssembly: Docker Without Containers

#119

Post by riddleronroof »

mytherin wrote: post #44
batmansmk wrote: post #30

Earlier quoted context omitted.

You can compile any C / C++ app down to wasm. In fact that’s the raison d’être of the technology: to provide a portable safe way to run binaries. Here is a link to Postgres in wasm for instance: https://supabase.com/blog/postgres-wasm . The way it works is that instead of outputting assembly for a given architecture in the backend compiler, it outputs wasm instructions that are designed to map all architectures, not…

C/C++ code can certainly be compiled down to WASM, but you cannot interface with the operating system as you would in a normal C/C++ program. To get around that restriction postgres-wasm ships an entire Linux distribution that is run inside the browser. This comes with an immense performance penalty. To get an impression of the performance penalty, just run the following query: SELECT SUM(i) FROM generate_series(0, 1…

Thank you for these details. Always suspected these claims but hadn’t dug deep enough.

Seems like some X can now run in wasm should come with disclaimer (includes Linux)

Re: WebAssembly: Docker Without Containers

#120

Post by orf »

mike_hearn wrote: post #108
orf wrote: post #96

Earlier quoted context omitted.

You can’t run Postgres on the JVM. WASM is pretty different to the JVM. The JVM deals with a lot of higher level constructs like objects, constructors, virtual methods, the GC etc. Which is fine if the language you’re hosting works in that way. WASM is more like assembly - the raw intrinsics used by a hypothetical WASM CPU. So you can compile a lot more stuff to it, because it’s a more natural target than a much, muc…

Although that's true (ish... you can run WASM on the JVM now, and also LLVM bitcode), that takes you into the realm of why you'd want to. On the browser side, you could maybe make a ChromeOS style argument of just wanting to run everything in a browser no matter what, it's nice for it to be sandboxed etc. But if you look at what your Postgres is doing it's sort of a Linux VM, and you can run those already at full spe…

Let me rework and clarify my point here a bit.

The JVM has historically and famously sucked at sandboxing untrusted/partially trusted code. The JVM also isn’t a suitable compilation target for arbitrary and existing codebases.

WASM is built to sandbox untrusted/partially trusted code. WASM is built as a compilation target rather than a complete hosted VM with bells and whistles.

There are advantages and disadvantages to this. One advantage is language-agnosticism. Another might be around the ability to run user-supplied untrusted code in a much safer way. See Cloudflare functions.

One disadvantage is the lack of bells and whistles.

So, the answer to “why is this different to the JVM” is that.

Post reply on HN