Hacker News Reader

Comment by droobles | Hacker News Reader

Excuse me if I come across as naive, I'm kind of a noob on these architectural topics, but how is this different/better than what the JVM is/accomplishes? When WASM first popped up I thought about the similarities with Java Web Applets and Flash.

View on HN

1. It's an open standard that the major browsers have agreed to, so it's not a plugin that you have to install. A WASM app will work seamlessly in your browser without any additional software.

2. WASM is designed from the ground up as a compile target, not a language. We already see many languages with support for building to WASM. C, C++, Rust, and eventually when WASM supports garbage collection we'll probably see Python, JS, Go, all with support for compiling to WASM.

Go already can be compiled to WASM, and it is likely that the Go GC will always perform better than the WASM one for Go applications (with some minor exceptions)

The current Go implementation is pretty slow for a number of reasons though.

GCs usually need low level system acces in a way that is not supported by WASM for obvious reasons (security, sandboxing, ...). Go also has problems with the way they implement Goroutines if I remember correctly.

WASM will definitely need some kind of GC bridge to make things efficient for garbage collected languages. Potentially with certain primitives exposed that make shipping your own GC efficient. We'll see how it develops.

UNCOL and TIMI reborn.

(1) could be resolved by shipping Java, let's say hypothetically.

(2) the JVM was designed from the ground up as a compile target also, for Java, but is also used by Kotlin, Clojure, Ruby (JRuby), Python (Jython) and Scala, among others. Even JavaScript (Rhino, Nashorn and Graal).

The JVM was designed as a compile target for a very particular kind of language. One with a Java-like object model, with some later concessions for more dynamic languages.

C, C++, Rust, etc. do not fit into that model at all. There's a lot of software written in C, and there's a lot of performance to be gained by dropping down to that level when necessary.

By later concessions do you mean invokedynamic? How much did it help? Clojure doesn't use it even now, 8 years after it came about, I think. Is it mostly for JRuby?

The JVM is (and was from the start) a lot more dynamic than Java.

But Oracle.

I wrote a blog post about that a few months back, here's the HN discussion https://news.ycombinator.com/item?id=17616459

This is an excellent write up, thank you!

Among other things, Oracle has been… not very friendly to people and organisations working with the JVM[1]. A standard with many implementations that isn't controlled by one corporation is desirable. With that said, I kind of wish that this standard was RISC-V, but I guess it doesn't work that well for virtual machines?

[1]: https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google....

I have been wondering this, it seems to me that it is potentially related to the memory allocation strategy for WASM should be more flexible than using something like the JVM

Java applets and Flash are dead. WASM isn't.

Reply on news.ycombinator.com