4 ms·

One way of looking at it that helped me wrap my head of why “this time is different”, is that Wasm is not so much as a language but a compilation target (as say

One way of looking at it that helped me wrap my head of why “this time is different”, is that Wasm is not so much as a language but a compilation target (as say x86) so it can really run anything

pletnes 4y ago
That’s what JVM promised! They just made Java so there would be at least one familiar-looking (to C++ devs) language for it. Indeed, there are quite a few JVM languages out there, just not as many as some had hoped in 1995.
cle 4y ago
The JVM executes Java bytecode, which is a compilation target for Java and many other languages. In this regard, architecturally it is exactly the same.
- acdha 4y ago
  Kind of - it was designed for Java so other languages were suboptimal for a long time, especially dynamic ones. Combined with the low quality of Java application servers and tooling, that approach was unpopular by the time things like InvokeDynamic matured and then Oracle’s licensing moves gave a lot of places reason for caution.
  - int_19h 4y ago
    The biggest problem when compiling to JVM bytecode isn't dynamic languages - even if they are slower, it's tolerable. It's stuff like C++, where the whole point is being fast, but JVM simply lacks the necessary primitives to compile to.
FlyingSnake 4y ago
Scala, Kotlin, Groovy proved that JVM can be used as a compilation target. Same was proven with Iron* languages on CLR. How is it different this time?
pbecotte 4y ago
It can run "anything" ... so long as someone has set up that project to correctly compile to a wasm target. "docker build" lets you build a package out of any software, without having to know much about it. "setting up a compiler for a new project, given the source code and maybe a separate toolchain for some other target that works", is a much more involved task. There is no world where people are just grabbing an existing app and saying "hey, I'm gonna drop this into my wasm runtime real quick"

One way of looking at it that helped me wrap my head of why “this time is different”, is that Wasm is not so much as a language but a compilation target (as say x86) so it can really run anything

pletnes 4y ago

That’s what JVM promised! They just made Java so there would be at least one familiar-looking (to C++ devs) language for it. Indeed, there are quite a few JVM languages out there, just not as many as some had hoped in 1995.

cle 4y ago

The JVM executes Java bytecode, which is a compilation target for Java and many other languages. In this regard, architecturally it is exactly the same.

acdha 4y ago
Kind of - it was designed for Java so other languages were suboptimal for a long time, especially dynamic ones. Combined with the low quality of Java application servers and tooling, that approach was unpopular by the time things like InvokeDynamic matured and then Oracle’s licensing moves gave a lot of places reason for caution.
- int_19h 4y ago
  The biggest problem when compiling to JVM bytecode isn't dynamic languages - even if they are slower, it's tolerable. It's stuff like C++, where the whole point is being fast, but JVM simply lacks the necessary primitives to compile to.

FlyingSnake 4y ago

Scala, Kotlin, Groovy proved that JVM can be used as a compilation target. Same was proven with Iron* languages on CLR. How is it different this time?

pbecotte 4y ago

It can run "anything" ... so long as someone has set up that project to correctly compile to a wasm target. "docker build" lets you build a package out of any software, without having to know much about it. "setting up a compiler for a new project, given the source code and maybe a separate toolchain for some other target that works", is a much more involved task. There is no world where people are just grabbing an existing app and saying "hey, I'm gonna drop this into my wasm runtime real quick"