Hacker News Reader

Comment by the_duke | Hacker News Reader

There are fundamental differences here.

Webassembly is a small stack machine based on an open standard.

It is built bottom up, with a very small core. Additional features like SIMD, garbage collection,posix style system interfaces (WASI), linking, garbage collection,... are built as optional extensions based on real world feedback.

There already are a multitude of different implementations. (the three browsers, the Wasm3 interpreter, wasmtime, Wasmer, ... )

Java, in contrast, was and is a huge runtime , not based on a standard, and has extremely complex semantics, many of them tied to a single language model.

Wasm is already seeing adoption across a wide range of domains.

I do believe the potential for WASM to succeed where Java failed is wide open.

View on HN

With all due respect, do you know anything about Java?

What do you think it is? https://docs.oracle.com/javase/specs/jvms/se7/html/

And no, Java is absolutely not a huge runtime - it is a simple stack-based vm with garbage collection made originally for goddamn TV set-top boxes, so it has an absolutely small instruction set. It just happens to be so good for multitudes of reasons that the biggest implementation (yes, it has absolutely insane amount of ones, tour claim of wasm having multiple implementations is just ridiculous compared to the amount of jvms), OpenJDK basically runs the backend of a great deal of all significant web applications.

Fun exercise: write a simple compiler with a JVM output. The JVM stack language is so easy, and it's the best way to explore it / something like it!

(Otherwise you're spot on and the GP clearly has no idea about Java)

I am (somewhat) familiar with the JVM.

Yes, it's also a stack based VM that is relatively small, at least superficially.

It's really not that simple though. Things like GC, exception handling, a whole class model with constructors and methods, ... All of that brings countless implicit requirements that are only passingly mentioned in the spec. Plus the whole host of complexity needed in practice for supporting the Java Platform.

Core Webassembly has nothing of that.

But to be fair: Webassembly is also growing more and more complex (SIMD, reference types, GC, interface types, module linking, tail calls, exceptions, ...)

Can the JVM be what Webassembly is? Or the CLR, for that matter? Technically: of course.

My point was really more about the ecosystem as a whole. JVMs were never really intended as a general purpose, multi/cross language ecosystem of generic computation. And everything around it is noticeable. In the build tooling, in the libraries, in the development process and focus, the lack of AOT until recently (in open source implementations), ....

Sure, that's changing now with GraalVM and a focus on cross language support. There are some extremely cool things happening there.

I'd still much rather bet on an ecosystem based on an open standard with lots of interest from different parties.

In fact, GraalVM already supports Webassembly, including WASI! So in certain sense Wasm is already more general.

> the lack of AOT until recently (in open source implementations)

The gcc project had a now discontinued AOT java compiler 2 decades ago.

Java is as open as it gets, with a standard, that can be changed through a community process. I feel the web is much less open with behemoths having basically infinite veto powers like google apple microsoft.

> In fact, GraalVM already supports Webassembly, including WASI! So in certain sense Wasm is already more general.

And teavm can run java byte code both in js as well as wasm :D

> Java is as open as it gets, with a standard, that can be changed through a community process.

Isn't the JCP also controlled by a hand full of corporations? Seems pretty much the same to me.

> And teavm can run java byte code both in js as well as wasm

Hah! I didn't know TeaVM had a WASM target, that's actually great to know.

> The gcc project had a now discontinued AOT java compiler 2 decades ago.

Was that ever really production ready?

Yes, Red-Hat used to AOT compile Eclipse with it.

So, honest question. if we're compiling our code to run on servers, why are we compiling it to run on a bytecode interpreter rather than native?

My single use for docker is to containerize / isolate, not to run across architectures.

I get the in-browser optimized / compiled code. That makes sense.

Wasm doesn't have to run in an interpreter. Many of the runtimes (like Wasmtime, Wasmer) compile the Webassembly to native machine code first. But that native code is still constrained by the Wasm security/sandboxing model, which includes memory isolation. (there is no direct memory sharing between the host and a Webassembly instance)

A few benefits why it is even useful in a server context:

You can distribute a single (small!) artifact and run it everywhere. On a developer machine, on Windows, on a x86 server, on an ARM server, ... Right now you have to build a separate Docker image for each architecture. And Docker is really a second class citizen on Windows.

Docker images have a huge dependency: an entire operating system syscall API and an entire userspace (with libraries, binaries, a file system, ...) The surface for a Wasm module is much smaller.

Building a Docker image is a somewhat redundant exercise of picking a base image, figuring out the dependencies, keeping it up to date, ... None of that should be necessary.

Security is another benefit. The vulnerability exposure of a Wasm module is much lower than that of an entire OS + userspace sandbox.

Wasm is designed around isolation. In addition, the interface types proposal + WASI is pushing capability based security that works by passing around capabilities, which is a pretty great model.

I outlined some more benefits here a few days ago: https://news.ycombinator.com/item?id=30020121&p=2#30020964

One thing I am missing here. Docker, as much as it has the shortcomings you list, has an entire fleet of posix libraries, utils and tools at its availability. This has meant 99% of applications could wholesale lift their application and deploy it within a container. When I look at WASM/WASI there is no networking API, no storage API, crypto, etc etc. I can see its value for offloading parts of a web application that require a more speedy execution, but I cannot see anyway of running a full headless application which is where containers are hugely utilised right now.

Yeah, progress on WASI has been painfully slow.

I think a big reason is that it was pushed by Mozilla, but they laid off all the related employees, and now no-one is really allocating resources to push it forward.

Plus it's still blocked by related proposal like interface types.

I know what WASI is, my point is that there is no where near parity with existing posix implementations. I have been following the bytecode alliance and webassembly communities for a while and they can't seem to get beyond the design phase. You only need to look at the networking API [0] and the thread has not been updated for two months, with prior to that folks asking is the work even happening still

[0] https://github.com/WebAssembly/WASI/issues/370

What's preventing the compilation of dependencies to WASM? Couldn't I (at extreme) run an alpine linux container distro inside WASM? At that point we're full circle, but it should be possible, right?

Very informative, thank you.

Thanks for the explanations.

What is that wasm project you're working on, if it has been publicly announced / released? It sounds very similar to Microsoft's Krustlet.dev and Suborbital's Atmo: https://github.com/suborbital/atmo

A little bit of an addendum: what will make or break WASM is language support.

If enough languages get official or high quality wasm targets, it has a bright future.

Sadly progress has stalled a little bit here, partially due to very slow progress on some features important for higher level languages.

But we'll see how things develop.

Reply on news.ycombinator.com