<https://twitter.com/solomonstre/status/1111131559...

# webassembly

[sdeleuze]

https://twitter.com/solomonstre/status/1111131559761833984

[Ruckus]

So... Graal?

[sdeleuze]

Graal is interesting, but if the ultimate goal is to escape from the JVM for production to be more efficient, maybe that means we can keep JVM style language like Kotlin and just go Native directly (Kotlin/Native) or using an ubiquitous bytecode designed for efficiency hence Kotlin/WebAssembly for mobile/iot/cloud.

[sdeleuze]

Also Graal or Kotlin/Native provide no universal deployment format, only WebAssembly can solve that.

[Ruckus]

... if the ultimate goal is to escape from the JVM ...

I was specifically commenting on the "ubiquitous runtime..." part. Don't get me wrong, WASM is amazing, but it's basically just another byte code.

[Ruckus]

only WebAssembly can solve that

No, it can't. It's just an IR. But "VM"s like WASI can.

[Ruckus]

Basically, my point is that comparing WASM to the JVM doesn't make sense. WASI to the JVM would make more sense. There's nothing stopping anyone from using JVM Byte Code exactly the same way WASM is used. You shouldn't conflate the language with the platform in these kinds of discussions (where the difference is significant)

[sdeleuze]

I see your point. My intent when I say WebAssembly is more to refer to WebAssembly ecosystem that includes runtime, WASM bytecode, WASI, etc.

[Ruckus]

Indeed, and that's usually just fine, but in this case I felt the distinction was important.

Ultimately, if the WebAssembly ecosystem can reach its stated goals while becoming as rich as the JVM and its associated ecosystem, it will be a force to be reckoned with. I'm quite excited to see how it turns out.

[sdeleuze]

Yeah + it would be a good fit with "the device where you run your application should be just configuration" principle that will gain traction is upcoming years IMO