4 ms·

Seems to have a lot more momentum though? I can run Haskell on WASM, and all the backends for JVM and CLR are long dead. More to the point, I can target the bro

Seems to have a lot more momentum though? I can run Haskell on WASM, and all the backends for JVM and CLR are long dead. More to the point, I can target the browser without plugins, lock-in, or security problems.

pjmlp 2y ago
And in a couple of years the same will most likely happen to the WASM backend. That was already possible with Haskell to JavaScript.
- pie_flavor 2y ago
  For all browser targets to die, people must no longer be interested in writing Haskell while writing webapps, even though people will probably remain interested in writing Haskell, and probably remain writing webapps, which seems unlikely. For the WASM target to die and the JS target to remain, this would have to mean that there is some technical barrier that makes the maintenance burden not worth the staggering performance gain, and if there is some such burden I am not aware of it. 'Java died so WASM will die because both are VMs' is basically a content-free dismissal - what do you actually think will no longer be needed, or is currently not needed but overvalued, and why?
  - pjmlp 2y ago
    Yet we are talking about targeting the server in this thread, because so far the tooling for the browser sucks, and VCs are more willing to sponsor startups selling server products. Java not only is pretty much alive on the server, so is .NET, Erlang, and plenty of compiled languages that have always been a better alternative to JavaScript.
    - pie_flavor 2y ago
      I am comparing your words about WASM to your words about JS. Misdirections about VCs are irrelevant. You can expect the WASM target to have as great or greater longevity than the JS target, and if your prediction about future failure isn't true of JS then it won't be true of WASM.
      - pjmlp 2y ago
        WASM on the server isn't the same as JS on the browser.
        pie_flavor 2y ago
        And that surely has something to do with the price of tea in China. WASM on the client is why you mentioned JS.
stult 2y ago
Also we have suffered a couple decades of JavaScript to give us that little extra motivation to make a common runtime environment work. And WASM is open source and thus not proprietary. And all the browsers (well, really, the one browser) are open source. The FOSS community is much more robust than it was 30 years ago, and there are many times more professional software devs floating around too, and security tooling and practices are substantially better now. Personally though I think the general antipathy for JavaScript and its endless parade of duplicative over hyped frameworks alone would suffice to push WASM forward.
- pjmlp 2y ago
  And yet, most of the efforts are geared towards using it outside of the browser, where better alternatives to JavaScript have always been available.

pjmlp 2y ago

And in a couple of years the same will most likely happen to the WASM backend. That was already possible with Haskell to JavaScript.

pie_flavor 2y ago
For all browser targets to die, people must no longer be interested in writing Haskell while writing webapps, even though people will probably remain interested in writing Haskell, and probably remain writing webapps, which seems unlikely. For the WASM target to die and the JS target to remain, this would have to mean that there is some technical barrier that makes the maintenance burden not worth the staggering performance gain, and if there is some such burden I am not aware of it. 'Java died so WASM will die because both are VMs' is basically a content-free dismissal - what do you actually think will no longer be needed, or is currently not needed but overvalued, and why?
- pjmlp 2y ago
  Yet we are talking about targeting the server in this thread, because so far the tooling for the browser sucks, and VCs are more willing to sponsor startups selling server products. Java not only is pretty much alive on the server, so is .NET, Erlang, and plenty of compiled languages that have always been a better alternative to JavaScript.
  - pie_flavor 2y ago
    I am comparing your words about WASM to your words about JS. Misdirections about VCs are irrelevant. You can expect the WASM target to have as great or greater longevity than the JS target, and if your prediction about future failure isn't true of JS then it won't be true of WASM.
    - pjmlp 2y ago
      WASM on the server isn't the same as JS on the browser.
      - pie_flavor 2y ago
        And that surely has something to do with the price of tea in China. WASM on the client is why you mentioned JS.

stult 2y ago

Also we have suffered a couple decades of JavaScript to give us that little extra motivation to make a common runtime environment work. And WASM is open source and thus not proprietary. And all the browsers (well, really, the one browser) are open source. The FOSS community is much more robust than it was 30 years ago, and there are many times more professional software devs floating around too, and security tooling and practices are substantially better now. Personally though I think the general antipathy for JavaScript and its endless parade of duplicative over hyped frameworks alone would suffice to push WASM forward.

pjmlp 2y ago
And yet, most of the efforts are geared towards using it outside of the browser, where better alternatives to JavaScript have always been available.