4 ms·

It seems to me like all languages are converging towards something like WASM. I wonder if in 20 years we will see WASM become the de facto platform that all app

It seems to me like all languages are converging towards something like WASM. I wonder if in 20 years we will see WASM become the de facto platform that all apps can compile to and all operating systems can run near-natively with only a thin like WASI but more convenient.

berkes 1y ago
Wasn't this the idea of the JVM?
- foldr 1y ago
  And of course the ill-fated Parrot VM associated with the Perl 6 project.
  - rhdjsjebshjffn 1y ago
    I think that was more of a language-oriented effort rather than runtime/abi oriented effort.
    - foldr 1y ago
      Parrot was intended to be a universal VM. It wasn’t just for Perl. https://www.slideshare.net/slideshow/the-parrot-vm/2126925 https://www.slideshare.net/slideshow/the-parrot-vm/2126925
      - rhdjsjebshjffn 1y ago
        Sure, I just think that's a very odd way to characterize the project. Basically anything can be universal vm if you put enough effort to reimplementing the languages. Much of what sets Parrot aside is its support for frontend tooling.
        foldr 1y ago
        “The Parrot VM aims to be a universal virtual machine for dynamic languages…” That’s how the people working on the project characterized it.
        rhdjsjebshjffn 1y ago
        I certainly think the humor in parrot/rakudo (and why they come up today still) is how little of their own self image the proponents could perceive. The absolute irony of thinking that perl's strength was due to familiarity with text-manipulation rather than the cultural mass....
- 90s_dev 1y ago
  I think so, but that was the 90s where we needed a lot more hindsight to get it right. Plus that was mostly just Sun, right? WASM is backed by all browsers and it looks like MS might be looking at bridging it with its own kernel or something?
  - lloeki 1y ago
    > that was the 90s In the meantime the CLR happened too. And - to an extent - LLVM IR.
  - bgwalter 1y ago
    I don't know. The integration of Java applets was way smoother than WASM. Security wise, perhaps a different story, though let's wait until WASM is in wide use with filesystem access and bugs start to appear.
    - berkes 1y ago
      I understand why, but still lament that java applets where dropped like a hot potato, rather than solving the (fundamental) issues. Back then, I learned Java, just to have fancy menus, quirky gimmicks and such. Until flash came along, nothing could do this. Where Java was rather open, free/libre, flash was proprietary and even patented. A big step back. And it took decades before JavaScript reached parity in possibilities to create such interactive, multimedia experiences in a cross-browserish way. I can only imagine how much further along something like videoconferencing, realtime collaboration or gaming on the web would've been if this Java applet tech had been ever improving since inception. (edit: I'm all for semantic, accessible ,clean HTML/CSS/JS in my web apps. But there's lots of use cases for gimmicks, fancy visuals, immersive experiences etc. and no, that's not the hotel-reservation-form or the hackers-forum. But art. Or fun. Or ?)
- hueho 1y ago
  Java bytecode was originally never intended to be used with anything other than Java - unlike WASM it's very much designed to describe programs using virtual dispatch and automatic memory management. Sun eventually added stuff like invokedynamic to make it easier to implement dynamic languages (at the time, stuff like Ruby and Python), but it was always a bit of round peg in square hole. By comparison, WASM is really more like traditional assembly, only running inside a sandbox.
  - pjmlp 1y ago
    Just like CLR bytecode, IBM i TIMI bytecode and many others since 1958. For some reason when people advocate for WASM outside of the browser, they only remember of the JVM.
- taf2 1y ago
  It’s not a bad idea. Lot of the same people who worked on JVM were around while the asm - wasm ideas emerged
zerd 1y ago
Like predicted in 2014 here: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
pjmlp 1y ago
This has been an idea since UNCOL was discussed as idea back in 1958. https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/UNCOL There are countless bytecode based platforms since 1958, including all famous Xerox PARC systems (the CPUs were microcoded and loaded the related translation code on boot), yet WASM is doing it first keeps being brought up. Do you know what I call WASI containers running on a Kubernetes cluster, or serverless cloud vendors? Application Server, https://en.wikipedia.org/wiki/Application_server https://en.wikipedia.org/wiki/Application_server
- writebetterc 1y ago
  Multi-tenancy on the JVM makes me shudder, though. The general point you're making, thumbs up to that.

berkes 1y ago

Wasn't this the idea of the JVM?

foldr 1y ago
And of course the ill-fated Parrot VM associated with the Perl 6 project.
- rhdjsjebshjffn 1y ago
  I think that was more of a language-oriented effort rather than runtime/abi oriented effort.
  - foldr 1y ago
    Parrot was intended to be a universal VM. It wasn’t just for Perl. https://www.slideshare.net/slideshow/the-parrot-vm/2126925 https://www.slideshare.net/slideshow/the-parrot-vm/2126925
    - rhdjsjebshjffn 1y ago
      Sure, I just think that's a very odd way to characterize the project. Basically anything can be universal vm if you put enough effort to reimplementing the languages. Much of what sets Parrot aside is its support for frontend tooling.
      - foldr 1y ago
        “The Parrot VM aims to be a universal virtual machine for dynamic languages…” That’s how the people working on the project characterized it.
        rhdjsjebshjffn 1y ago
        I certainly think the humor in parrot/rakudo (and why they come up today still) is how little of their own self image the proponents could perceive. The absolute irony of thinking that perl's strength was due to familiarity with text-manipulation rather than the cultural mass....
90s_dev 1y ago
I think so, but that was the 90s where we needed a lot more hindsight to get it right. Plus that was mostly just Sun, right? WASM is backed by all browsers and it looks like MS might be looking at bridging it with its own kernel or something?
- lloeki 1y ago
  > that was the 90s In the meantime the CLR happened too. And - to an extent - LLVM IR.
- bgwalter 1y ago
  I don't know. The integration of Java applets was way smoother than WASM. Security wise, perhaps a different story, though let's wait until WASM is in wide use with filesystem access and bugs start to appear.
  - berkes 1y ago
    I understand why, but still lament that java applets where dropped like a hot potato, rather than solving the (fundamental) issues. Back then, I learned Java, just to have fancy menus, quirky gimmicks and such. Until flash came along, nothing could do this. Where Java was rather open, free/libre, flash was proprietary and even patented. A big step back. And it took decades before JavaScript reached parity in possibilities to create such interactive, multimedia experiences in a cross-browserish way. I can only imagine how much further along something like videoconferencing, realtime collaboration or gaming on the web would've been if this Java applet tech had been ever improving since inception. (edit: I'm all for semantic, accessible ,clean HTML/CSS/JS in my web apps. But there's lots of use cases for gimmicks, fancy visuals, immersive experiences etc. and no, that's not the hotel-reservation-form or the hackers-forum. But art. Or fun. Or ?)
hueho 1y ago
Java bytecode was originally never intended to be used with anything other than Java - unlike WASM it's very much designed to describe programs using virtual dispatch and automatic memory management. Sun eventually added stuff like invokedynamic to make it easier to implement dynamic languages (at the time, stuff like Ruby and Python), but it was always a bit of round peg in square hole. By comparison, WASM is really more like traditional assembly, only running inside a sandbox.
- pjmlp 1y ago
  Just like CLR bytecode, IBM i TIMI bytecode and many others since 1958. For some reason when people advocate for WASM outside of the browser, they only remember of the JVM.
taf2 1y ago
It’s not a bad idea. Lot of the same people who worked on JVM were around while the asm - wasm ideas emerged

zerd 1y ago

Like predicted in 2014 here: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...

pjmlp 1y ago

This has been an idea since UNCOL was discussed as idea back in 1958. https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/UNCOL There are countless bytecode based platforms since 1958, including all famous Xerox PARC systems (the CPUs were microcoded and loaded the related translation code on boot), yet WASM is doing it first keeps being brought up. Do you know what I call WASI containers running on a Kubernetes cluster, or serverless cloud vendors? Application Server, https://en.wikipedia.org/wiki/Application_server https://en.wikipedia.org/wiki/Application_server

writebetterc 1y ago
Multi-tenancy on the JVM makes me shudder, though. The general point you're making, thumbs up to that.