Hacker News Reader

Comment by tasogare | Hacker News Reader

Genuine question: What does it bring new to the table?

Solomon Hykes, author of Docker: If WASM+WASI existed in 2008, we wouldn't have needed to created Docker. That's how important it is. Webassembly on the server is the future of computing. A standardized system interface was the missing link. Let's hope WASI is up to the task! cf https://twitter.com/solomonstre/status/1111004913222324225?l...

This is strange. WASM can't handle half the things Docker needs to run. I'm genuinely confused as to how he can say the two are equivalent in any way, despite being the author of docker.

VMs existed at the time. Java was one of them, probably the most prolific of them all, and certainly had a standardized system interface.

Further WASI is a nightmare. Most projects I've personally seen disregard it completely.

You are putting the cart before the Solomon. He is saying they would have built on WASM+WASI in the way that Docker is built on cgroups.

Java is not a target for C++ code compiled via Clang/LLVM. Wasm is.

Expert advice done cheap.

https://www.graalvm.org/reference-manual/llvm

Experts happen to know what is actually possible.

Graal has AoT, you cannot compile Java to native with LLVM. But you know this already. You cannot compile C++ to the JVM w/o heroics or interpreting a RISC machine (nestedvm).

Are you going to quip that Burroughs did all this already as well?

Of course you cannot compile Java to native with LLVM, the support isn't there, that doesn't mean there aren't other Java AOT compilers to choose from, like the now gone Excelsior JET, or PTC and Aicas still on the market.

Not Burroughs, but AS/400 TIMI (now IBM i), Microsoft MSIL, TenDRA compiler suite, if you want to talk about C++ aware bytecodes.

But... you can't. They still would have had to have built a custom VM that could forward full-on Syscalls, so Docker (or something similar) would still have to be written.

This still doesn't make sense to me. Cgroups are a Linux kernel feature, WASM is a VM. They do not have the same (or similar) scope of features.

You no longer need syscalls when you can interpose the whole runtime, you don't need cgroups either for a wasm process. Sandboxing becomes a purely user mode construct, no OS magic needed.

So you're saying you'd run an entire Linux kernel within a WASM VM?

You lose hypervisor speedups, kernel feature parity, introduce a whole new surface area for security exploits since you're throwing away the entirety of linux's history, and what's more, it was still possible with the JVM.

No, you live Linux behind (or below). You could run the entire OS in Wasm, but what does an OS mean when all the same affordances are now in userland?

Userland doesn't have any semblance of I/O. WASI doesn't support arbitrary syscalls, so running containers would not work in WASM.... I'm not seeing your solution to this. Docker and would-be-WASM-docker would have very, very different scopes and thus would not be comparable.

Both sides of the Wasm env are userland, you can expose any method you wish into the Wasm environment. You don't even need WASI, its just a crutch for programs that expect libc.

Wasm is two things, CFI and capabilities, everything else is an implementation detail.

Your definition of a container is too limited in scope. You don't understand what I or Solomon Hykes are saying wrt Wasm and isolation. I tried to help.

Here let me try:

What's important to understand is, Docker exists because Oracle made Java too scary to touch, thanks to big ongoing lawsuits against Google, and demanding royalties just for running a JVM server. Also the JVM is fast, but it's slow enough that it's within striking distance of a full cgroup, running a full Linux kernel.

So it made sense to just create Docker, and allow people to abandon things like jruby, and just run normal Ruby in a Docker container.

WASM is what people would have wanted when Docker was created. A bytecode format like JVM, but faster, and not encumbered by big bad Oracle's coffer-rattling.

So in other words, if WASM had existed when Docker was created, people would have just recompiled their apps for WASM bytecode, and would have also recompiled things like MongoDB and MariaDB for WASM. Things like network syscalls would be replaced by traps to the webassembly runtime.

> Java is not a target for C++ code compiled via Clang/LLVM. Wasm is

Well, it is with GraalVM with proper cross-language inlining.

He should have gone talk to Microsoft and learn about MSIL.

For me, the most interesting potential of WASM is it provides a platform-independent sandboxed way to run untrusted code written in multiple programming languages.

This means it's in theory possible to run the same code on an embedded hardware platform, a desktop app or in the browser.

And while I'm sure there's "serious" business uses for that capability :) I'm most interested in what it enables in terms of user customisation/modding of games.

Which was my main motivation for creating a Wasmtime WASM runtime add-on for the Godot game engine: https://gitlab.com/RancidBacon/godot-wasm-engine

And also designing the "WebAssembly Calling Card" specification as a way of demonstrating how the same code could produce graphical output that is then used in 2D or 3D environments: https://wacc.rancidbacon.com

This is exactly what I'm doing right now with SNES emulators, bsnes-plus specifically. The idea is to be able to extend certain games and give wasm module the ability to read/write the emulated memory and send/receive messages over a network connection to another process, among other things.

Sounds cool!

Do you have anywhere that interested people can read more about the project/progress?

Hm not really but I do update my repo on github.com. It's all work in progress stuff being designed as I go.

https://github.com/alttpo/bsnes-plus/tree/wasm/bsnes/wasm

> This means it's in theory possible to run the same code on an embedded hardware platform, a desktop app or in the browser.

Maybe want to talk to the Java guys, and ask them why this doesn't work out in practice? ;-)

Just having a common byte-code interpreter isn't enough for portability of applications.

Admittedly, "How is this different to Java [planned]?" isn't an entirely unreasonable question to ask in this context. :)

What's your theory on why it doesn't/didn't work out in practice in Java's case?

There is one key difference in our respective wording which might point to a difference of perspective:

I referred to "the same code" and you referred to "portability of applications".

I don't really foresee "portability of applications" so much as "portability of modules/functions" (or "portability of libraries/plugins", I guess).

In which case, you're still correct when you say a common byte-code interpreter isn't enough--there also needs to be common specification/API for specific domains. (Which is where WASI is aiming for in terms of general system-level APIs; interface types are aiming for lower levels; and, other higher level domain/application-specific solutions may be developed for other situations.)

> And while I'm sure there's "serious" business uses for that capability :)

There surely is, Java, .NET were there first.

If we leave the browser out, then there are plenty of examples since the early days of 1960's.

I think the main thing it brings is a portable compiler target that actually stands a chance at being widely adopted.

Think of WASM as a JVM alternative, but it has heavy sandboxing.

By default, WASM is pure computing. It can't interact with the outside world. You need to allow WASM to talk to the outside world explicitly.

You have native performance. It's fast.

It's platform-independent, and multiple languages can compile to WASM.

The properties lead to some useful applications.

Serverless, FaaS. If you use WASM for Serverless you get very fast execution + cold starts. Cloudflare Workers can do 200ms cold starts and 20ms a request. Fastly Cloud@Edge not being a Chrome browser, but instead, its own runtime can do better and serve requests in 10ms. The low overhead and secure sandboxing means you can bin-pack these at a massive scale and call them with little overhead. It's much more efficient than Lambda etc. Cloudflare and Fastly as edge CDN providers allow you to deploy fast apps, globally distributed by default, piggyback off their existing caching functionality with no need for API gateways/complex plumbing etc. Fastly's C@E is especially interesting. Unfortunately, Fastly have failed to capitalise on it product-wise. As a product, Cloudflare is way ahead. The best tech doesn't win. I'm not disparaging Cloudflare here. I personally use Cloudflare over Fastly because, at this point, Cloudflare are a more complete product/ecosystem with superior pricing model.

For serverless, it's early days but WASM/WASI will probably disrupt the current FaaS providers once the rough edges are worked out. I wish Fastly had a better product/business execution team to realise C@E properly.

Outside of Serverless/FaaS it makes massive sense instead of people deploying full OS's in a Docker image on Kubernetes, instead deploy WASM modules. Wasmcloud (https://wasmcloud.dev/) looks to be one of the first here running an actor system in Kuberenetes where the Actors are WASM apps.

The other place where it has big potential is to be the Electron from hardware devices. Here's a talk for building a WebAssembly runtime for IPlayer https://www.youtube.com/watch?v=28paRXqI-Gk . They essentially made the bulk of the logic/app in Webassembly then created small shims for different devices to load it. Webassembly allowed the hardware providers to offer a portable runtime that can execute 3rd party software in a restricted runtime.

WebAssembly in the browser is the least exciting part about WebAssembly. I'm incredibly excited to see how it is used for Microservices and serverless.

> By default, WASM is pure computing. It can't interact with the outside world. You need to allow WASM to talk to the outside world explicitly.

That only applies to MVP 1.0, the long term roadmap hardly makes it any different from the myriad of other bytecode distribution formats.

Reply on news.ycombinator.com