Hacker News Reader

Comment by readittwice | Hacker News Reader

All of your "serious flaws" are actually fixable. Obviously WASM tooling isn't as mature as other older ecosystems, this will get fixed over time.

I don't think JVMs where without any security bugs, since WASM is mainly used in browsers right now, security is a MAJOR concern. Java-Bytecode was designed for a different purpose. Try to compile a language with multi-inheritance to Java-Bytecode, it's a pain. WASM is designed in a more language-agnostic way, that's why GC and Exception Handling is much harder to specify than in the JVM.

BTW: GC'ed languages can already be compiled to WASM: they more or less "just" need to compile the GC to WASM too. The GC proposal would only allow to reuse the embedder's (most likely the browser) GC.

View on HN

Sure, but see the comment by munificent. You're saying, well JVM bytecode sucks because it's hard to compile C++ to because it lacks multiple inheritance, and arguing this makes WASM more language agnostic.

But. Then you admit that compiling Java to WASM is hard because there's no GC, you'd have to ship your entire GC with the app and it wouldn't be fast because GCs like to integrate with the JIT compiler and WASM is the JIT compiler here. Also WASM JITs don't really understand managed code patterns well.

So how is WASM more language agnostic? Seems like (if we ignore Graal) WASM has trouble with languages JVM bytecode is good at, and vice-versa. Quite comparable, no?

BTW even saying C++ is easy to compile to WASM is tricky because WASM apparently has no exception support, and exceptions are a part of the C++ language. Likewise for vendor extensions like vector intrinsics, inline assembly etc. At best you can handle a subset of the language.

So in the end I don't buy that it's really more generic. As munificent says, it seems more like people aren't really sinking their teeth into the tradeoffs involved.

Let me be clear on this: I am NOT saying that Java-Bytecode sucks. I am simply saying that WASM is better for the Web's use case. There is no shame in that, WASM was designed for that and could learn from the experience with many bytecode formats and also asm.js.

Even if we would agree that the JVM is as good as WASM as a language-agnostic bytecode, WASM still makes sense since it doesn't come with all the baggage of the JVM like class files, many bytecodes that exactly match the Java semantics but can't be used in other languages. Browser-vendors would still have to add new bytecodes for common operations for both size and speed reasons. So it made sense to design a new bytecode format. WASM even allows streaming compilation: The browser can start compiling bytecode before it downloaded the whole file.

Yes, there are a few features missing from WASM. But just look how many applications have already been compiled for the web. The missing features are not that relevant for many large existing and performance-sensitive native applications written in C/C++. We don't need to rewrite this applications in JS. I mean JS wouldn't even be fast enough for that anyways. That's what WASM was designed for and even according to you WASM is better suited for this than Java-Bytecode.

Inline assembly and vector extensions would also be problematic in Java Bytecode.

GC is planned and worked on.

Reply on news.ycombinator.com