8 ms·

Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. d

Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode. We're heading in circles in a lot of ways

syrusakbary 3y ago
Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly
- pookeh 3y ago
  There was a time when JVM ran in the browsers.
  - syrusakbary 3y ago
    Yup, via Java Applets. But they were a pain to use, that's why I intentionally wrote "seamlessly" :P
    - ex3ndr 3y ago
      GWT allowed to run it without applets, also much more efficient than any current stack (since they dont support closure compiler)
      - switchbak 3y ago
        I spent years working with GWT, it's not nearly as simple as you describe. It's not running "Java" in the browser, it's compiling down (a subset of) Java to Javascript. That said, GWT was ahead of its time in a lot of ways, but it had warts galore.
    - freeone3000 3y ago
      They were better than Flash (which needed a weirder runtime, and couldn’t interact easily with the DOM, and didn’t have variables until version 3). This is hugely improved over JavaScript at the time (pre-XHR) and had less lock-in than ActiveX.
    - wwweston 3y ago
      As far as I could tell, the big pain point was performance -- they were just too slow on median machines during the late 90s/early 00s window they had mindshare. I actually enjoyed using them to get around a few browser limitations around the mid-to-late 00s, and they seemed feature/performance competitive with Flash unless what you were doing fit the media authoring model closely. But by then people were skeptical about Java and if you had to do anything to get it installed they wouldn't, and the direction was native web.
      - pjmlp 3y ago
        The Java Kernel project sorted that out.
  - chunk_waffle 3y ago
    I recall around 2010 or so, when a company I worked for was creating a new, rather ambitions, web application. I had to argue against using Java Applets in favor of standard web technology for several components. Thankfully I won that battle. That web application is still in use, in production, today.
- pitaj 3y ago
  I would also mention that, especially in the past, the JVM sandboxing was not great. Which is why Applets were such a problem.
  - KRAKRISMOTT 3y ago
    Not just in the past, arbitrary program sandboxing is not possible even today.
    - kllrnohj 3y ago
      Exactly, yet everyone pretends wasm is the exception for some reason...
      - nequo 3y ago
        I don't know about the limitations of sandboxing but I am curious. How does one break out of the JVM's or wasm's sandbox?
        KRAKRISMOTT 3y ago
        I meant decent sandboxing on the JVM is not possible, that’s the advantage of WASM.
        mike_hearn 3y ago
        The approach is the same in both cases - find an exposed API surface with a privileged implementation, find some way to confuse it, exploit. In a few cases there were JVM exploits that weren't based on that approach, almost always involving reflection or JIT compiler bugs. The people saying WASM is easier to sandbox than the JVM are sort of half right and half wrong. The hard part of sandboxing is exposing safe APIs to the sandboxed code. WASM solves that by simply not exposing any APIs at all. This essentially punts the sandbox construction to the user and will allow WASM vendors to claim a good security track record, which they will get by not doing very much. On the other hand, the OpenJDK guys are retreating from providing any sandbox at all and are taking it out of new Java versions. So you'll end up with mandatory exposed APIs that don't even try to be safe. Neither approach is really all that great if what you want is the ability to run a useful set of normal-ish programs in a safe way. GraalVM has its own sandboxing features which look like a decent compromise, and you can still use process or VM sandboxing on top.
- ThePhysicist 3y ago
  Funny that most people seem to have forgotten that browsers used to ship with Java support. Not saying that was a good thing, but 20 years ago you could run JVM apps in the browser without issues. Also, there are dozens of language runtimes for the JVM, e.g. Ruby, Python, Golang, Javascript, Scheme, .... And regarding proprietary software, Wasmer is a for-profit startup that seems to offer open-source tooling with the hope the ecosystem will standardize on it and give them opportunities to monetize that. So not that much unlike Java I'd say.
  - throwaway50609 3y ago
    Funny that you forgot about all the security issues of JVM applets that Wasm finally solved
    - baq 3y ago
      And now you can run a wasm jvm: https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ (there are others, too)
    - eyberg 3y ago
      Like this one? #include <stdio.h> #include <stdlib.h> int main() { char *s = "world"; s[0] = 'o'; s[1] = 'w'; s[2] = 'n'; s[3] = 'e'; s[4] = 'd'; printf("Hello, %s\n", s); }
      - throwaway50609 3y ago
        Just compiled and ran it on my system within Wasm, my computer is still fine. Your point? The point of Wasm is - programs can and will malfunction (and some will be malicious), so we have to protect the environment that runs it.
        deleted 3y ago
        [deleted]
  - deleted 3y ago
    [deleted]
- yazzku 3y ago
  Memory usage too, right? A C++/Rust wasm won't consume a hundredth of the memory a JVM application typically uses. I like getting the job done on a 512MB RAM VPS. JVM the language might be cool; the bloat and forced-GC can be spared.
  - icedchai 3y ago
    JVM ran in relatively little memory back in the day. I remember running applets on ~16 megabyte systems. Compare that to today where you need a half gig of RAM to even launch a browser.
    - mhitza 3y ago
      Right, the internet caffee computers I used to hang out at in the early 2000's had around the 128-256mb of RAM memory, and Java/Flash used to run just fine. Although Java Applets usually seemed to take longer to download, and used to wait a lot of time to start the JVM after that.
  - pjmlp 3y ago
    Just like a JVM for embedded development won't.
  - jeroenhd 3y ago
    Java can be fast and memory efficient. The problem I see with many Java programs is that they're built on top of layers upon layers of frameworks. Web server frameworks on top of multithreading frameworks with database ORM frameworks and microservice frameworks all calling in and out of each other. Stack traces that end up accumulating 30 or 40 calls before actual product code even begins. Tuning the garbage collector often helps, modern Java has excellent GC options that will make most software just run better. That's often not an option when you're stuck with JRE 8 because of the curse of legacy code, but modern JREs have made significant progress in both memory management and general performance optimizations. Port the same abstractions to any language and you'll get very similar performance issues. I've seen plenty of NodeJS applications crash because they grew out of the 2GiB memory limit I set up, and those node processes weren't doing anything that I deemed worth more than half a gigabyte of RAM either. The JVM is somewhat aggressive in claiming RAM as memory usage grows, but that often leads to a performance increase in the comparisons I've done. Setting parameters (-xmx / -xms) can often reduce the amount of memory used significantly at the cost of slower application startups.
- michaelmior 3y ago
  > you could not run C programs in the JVM Not entirely true, but of course there has never been any official support. http://nestedvm.ibex.org/ http://nestedvm.ibex.org/
- deleted 3y ago
  [deleted]
- tubs 3y ago
  You can't run c in wasm. You can compile c to wasm and run that. In the same way one could compile c to java byte code, write a wrapper program to allocate the "heap", disable the gc and execute it in close to the same way it executes in a wasm runtime.
- 0xbadcafebee 3y ago
  I'm still flabbergasted that all these people, in the year 2023, think a hypertext markup document viewer with a terrible UX and bizarre design restrictions that takes 4GB of RAM to run and re-implements the features of an entire operating system is the end-all be-all of technology. If it doesn't run in a web browser it's worthless. I can't even come up with a metaphor for it. We're choosing to be stuck with shitty antiquated technology because it's easier than making something better. It's depressing. Like a world that never got past the horse and buggy. Large engines powered by steam would require additional investment in refining of steel and making giant cast or forged parts... easier to just stick with the horse.
  - reginaldo 3y ago
    The browser "won" on seamless distribution. The browser is all the things you said and worse. It conflates the developer API (which could be as complex as the collective human comprehension will allow) with the execution environment (which must be as simple as possible and understandable to mostly anyone). I have a dream that the browser will turn inside out and start losing APIs that will be reimplemented on WebAssembly. But WebAssembly is moving too slowly e.g. with regards to tail calls and parallelism. So it's probably just a dream from now[1]. [1] https://www.youtube.com/watch?v=zlQEQQSqZ9g https://www.youtube.com/watch?v=zlQEQQSqZ9g -> it's an old dream that others have had before.
  - MR4D 3y ago
    Unfortunately, the world is scheduled to end (or reboot if you prefer) at 03:14:07 UTC on January 19th, 2038. [0] So, that means that the remake of an OS that we call a browser is likely to be the pinnacle of computing for our lifetimes. Hopefully after the Great Reboot of 2038, the next generation will learn from our computing mistakes, but since we've never learned from those that came before us, it's highly unlikely. But at least they will have to start from scratch, so there's a chance! [0] - https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
  - mch82 3y ago
    > Like a world that never got past the horse and buggy At lunch one day a colleague explained that the size of the space shuttle could be linked to the width of two horses walking on a Roman road :-) One of my favorite lunch breaks of all time.
- mdellavo 3y ago
  It's not an open standard but the JVM spec is publically available and intended for multiple implementations https://docs.oracle.com/javase/specs/jvms/se8/html/ https://docs.oracle.com/javase/specs/jvms/se8/html/
pjmlp 3y ago
It is incredible how with so much Java hate, the WASM folks are doing their best to replicate everything we had in 2005.
- nu11ptr 3y ago
  Honestly, I just think Java was ahead of its time. I hated sites with applets because they felt slow to startup and run. That problem is long gone with modern computers.
- dianeb 3y ago
  Sure, this fits the way software evolves on the circle of dumb. It goes something like this: What a great idea!... (a little later) Hmmm. That's a problem... (later) We need something to run apps in the browser. I wonder if WASM would work... (now) What a great idea!... Software development always goes in cycles. "Apps" were great now maybe not so much so... In the late 80s/early 90s, the CEO of ETA Systems (a supercomputer company) had a vision that by 2000, the world would be split between supercomputers and workstations. I have seen some evidence that people are considerng that once again... The Circle of Dumb is always with us in software land.
  - frou_dh 3y ago
    As long as it's refining and making at least some progress then it's more of a helix than a circle
    - Y_Y 3y ago
      I see it as more of a conical spiral, like water going down a drain.
- moonchrome 3y ago
  Java still doesn't have value types AFAIK. Meanwhile WASM started out as no-gc continuous memory VM. Comparing WASM and JVM is like comparing a truck and a bus because they are relatively the same size, move at the same speed etc. I mean sure you can load people in trucks and cargo into buses - and both have been done with JVM (eg. people built C compilers) and WASM (people are building GCed runtimes on top of it despite lack of GC support from platform). Almost 30 years later nobody sane is running C on JVM and there were many attempts posted here over the years.
gabereiser 3y ago
I was just going to say, this road leads to OSGi...
tiffanyh 3y ago
Don't forget, a mail server will be included at some point since that always seems inevitable.
mc_woods 3y ago
> Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. You mean in a OCI image, a bit like this? - https://docs.docker.com/desktop/wasm/ https://docs.docker.com/desktop/wasm/ and then deployed using Kubernetes? - a bit like this - https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-pools https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-po...
benatkin 3y ago
The delivery of assets sounds like a job for Bindle which is already integrated to Spin, which looks to be more similar to python's WSGI than this https://www.fermyon.com/spin https://www.fermyon.com/spin https://www.fermyon.com/blog/bindle-what-is-it https://www.fermyon.com/blog/bindle-what-is-it
- syrusakbary 3y ago
  Bindle is one of the worst specifications of a container format I've ever seen, I would personally recommend anyone to stay away from it. No wonder they are ditching it in favor of OCI...
herdcall 3y ago
Multi language support is just one of the selling points, you didn't mention the other two: sandboxed security with explicit capabilities and high performance. E.g., I have a Web Assembly module running on the server (Fermyon) that needs explicit capabilities defined to even make a network call to a Twilio endpoint or read a local file. That means you can run a random Web Assembly module that you with confidence, just like you can typically open a random website on the browser without concern. By contast, you can't say that when running a random Java class that you don't trust.

syrusakbary 3y ago

Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly

pookeh 3y ago
There was a time when JVM ran in the browsers.
- syrusakbary 3y ago
  Yup, via Java Applets. But they were a pain to use, that's why I intentionally wrote "seamlessly" :P
  - ex3ndr 3y ago
    GWT allowed to run it without applets, also much more efficient than any current stack (since they dont support closure compiler)
    - switchbak 3y ago
      I spent years working with GWT, it's not nearly as simple as you describe. It's not running "Java" in the browser, it's compiling down (a subset of) Java to Javascript. That said, GWT was ahead of its time in a lot of ways, but it had warts galore.
  - freeone3000 3y ago
    They were better than Flash (which needed a weirder runtime, and couldn’t interact easily with the DOM, and didn’t have variables until version 3). This is hugely improved over JavaScript at the time (pre-XHR) and had less lock-in than ActiveX.
  - wwweston 3y ago
    As far as I could tell, the big pain point was performance -- they were just too slow on median machines during the late 90s/early 00s window they had mindshare. I actually enjoyed using them to get around a few browser limitations around the mid-to-late 00s, and they seemed feature/performance competitive with Flash unless what you were doing fit the media authoring model closely. But by then people were skeptical about Java and if you had to do anything to get it installed they wouldn't, and the direction was native web.
    - pjmlp 3y ago
      The Java Kernel project sorted that out.
- chunk_waffle 3y ago
  I recall around 2010 or so, when a company I worked for was creating a new, rather ambitions, web application. I had to argue against using Java Applets in favor of standard web technology for several components. Thankfully I won that battle. That web application is still in use, in production, today.
pitaj 3y ago
I would also mention that, especially in the past, the JVM sandboxing was not great. Which is why Applets were such a problem.
- KRAKRISMOTT 3y ago
  Not just in the past, arbitrary program sandboxing is not possible even today.
  - kllrnohj 3y ago
    Exactly, yet everyone pretends wasm is the exception for some reason...
    - nequo 3y ago
      I don't know about the limitations of sandboxing but I am curious. How does one break out of the JVM's or wasm's sandbox?
      - KRAKRISMOTT 3y ago
        I meant decent sandboxing on the JVM is not possible, that’s the advantage of WASM.
      - mike_hearn 3y ago
        The approach is the same in both cases - find an exposed API surface with a privileged implementation, find some way to confuse it, exploit. In a few cases there were JVM exploits that weren't based on that approach, almost always involving reflection or JIT compiler bugs. The people saying WASM is easier to sandbox than the JVM are sort of half right and half wrong. The hard part of sandboxing is exposing safe APIs to the sandboxed code. WASM solves that by simply not exposing any APIs at all. This essentially punts the sandbox construction to the user and will allow WASM vendors to claim a good security track record, which they will get by not doing very much. On the other hand, the OpenJDK guys are retreating from providing any sandbox at all and are taking it out of new Java versions. So you'll end up with mandatory exposed APIs that don't even try to be safe. Neither approach is really all that great if what you want is the ability to run a useful set of normal-ish programs in a safe way. GraalVM has its own sandboxing features which look like a decent compromise, and you can still use process or VM sandboxing on top.
ThePhysicist 3y ago
Funny that most people seem to have forgotten that browsers used to ship with Java support. Not saying that was a good thing, but 20 years ago you could run JVM apps in the browser without issues. Also, there are dozens of language runtimes for the JVM, e.g. Ruby, Python, Golang, Javascript, Scheme, .... And regarding proprietary software, Wasmer is a for-profit startup that seems to offer open-source tooling with the hope the ecosystem will standardize on it and give them opportunities to monetize that. So not that much unlike Java I'd say.
- throwaway50609 3y ago
  Funny that you forgot about all the security issues of JVM applets that Wasm finally solved
  - baq 3y ago
    And now you can run a wasm jvm: https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ (there are others, too)
  - eyberg 3y ago
    Like this one? #include <stdio.h> #include <stdlib.h> int main() { char *s = "world"; s[0] = 'o'; s[1] = 'w'; s[2] = 'n'; s[3] = 'e'; s[4] = 'd'; printf("Hello, %s\n", s); }
    - throwaway50609 3y ago
      Just compiled and ran it on my system within Wasm, my computer is still fine. Your point? The point of Wasm is - programs can and will malfunction (and some will be malicious), so we have to protect the environment that runs it.
      - deleted 3y ago
        [deleted]
- deleted 3y ago
  [deleted]
yazzku 3y ago
Memory usage too, right? A C++/Rust wasm won't consume a hundredth of the memory a JVM application typically uses. I like getting the job done on a 512MB RAM VPS. JVM the language might be cool; the bloat and forced-GC can be spared.
- icedchai 3y ago
  JVM ran in relatively little memory back in the day. I remember running applets on ~16 megabyte systems. Compare that to today where you need a half gig of RAM to even launch a browser.
  - mhitza 3y ago
    Right, the internet caffee computers I used to hang out at in the early 2000's had around the 128-256mb of RAM memory, and Java/Flash used to run just fine. Although Java Applets usually seemed to take longer to download, and used to wait a lot of time to start the JVM after that.
- pjmlp 3y ago
  Just like a JVM for embedded development won't.
- jeroenhd 3y ago
  Java can be fast and memory efficient. The problem I see with many Java programs is that they're built on top of layers upon layers of frameworks. Web server frameworks on top of multithreading frameworks with database ORM frameworks and microservice frameworks all calling in and out of each other. Stack traces that end up accumulating 30 or 40 calls before actual product code even begins. Tuning the garbage collector often helps, modern Java has excellent GC options that will make most software just run better. That's often not an option when you're stuck with JRE 8 because of the curse of legacy code, but modern JREs have made significant progress in both memory management and general performance optimizations. Port the same abstractions to any language and you'll get very similar performance issues. I've seen plenty of NodeJS applications crash because they grew out of the 2GiB memory limit I set up, and those node processes weren't doing anything that I deemed worth more than half a gigabyte of RAM either. The JVM is somewhat aggressive in claiming RAM as memory usage grows, but that often leads to a performance increase in the comparisons I've done. Setting parameters (-xmx / -xms) can often reduce the amount of memory used significantly at the cost of slower application startups.
michaelmior 3y ago
> you could not run C programs in the JVM Not entirely true, but of course there has never been any official support. http://nestedvm.ibex.org/ http://nestedvm.ibex.org/
deleted 3y ago
[deleted]
tubs 3y ago
You can't run c in wasm. You can compile c to wasm and run that. In the same way one could compile c to java byte code, write a wrapper program to allocate the "heap", disable the gc and execute it in close to the same way it executes in a wasm runtime.
0xbadcafebee 3y ago
I'm still flabbergasted that all these people, in the year 2023, think a hypertext markup document viewer with a terrible UX and bizarre design restrictions that takes 4GB of RAM to run and re-implements the features of an entire operating system is the end-all be-all of technology. If it doesn't run in a web browser it's worthless. I can't even come up with a metaphor for it. We're choosing to be stuck with shitty antiquated technology because it's easier than making something better. It's depressing. Like a world that never got past the horse and buggy. Large engines powered by steam would require additional investment in refining of steel and making giant cast or forged parts... easier to just stick with the horse.
- reginaldo 3y ago
  The browser "won" on seamless distribution. The browser is all the things you said and worse. It conflates the developer API (which could be as complex as the collective human comprehension will allow) with the execution environment (which must be as simple as possible and understandable to mostly anyone). I have a dream that the browser will turn inside out and start losing APIs that will be reimplemented on WebAssembly. But WebAssembly is moving too slowly e.g. with regards to tail calls and parallelism. So it's probably just a dream from now[1]. [1] https://www.youtube.com/watch?v=zlQEQQSqZ9g https://www.youtube.com/watch?v=zlQEQQSqZ9g -> it's an old dream that others have had before.
- MR4D 3y ago
  Unfortunately, the world is scheduled to end (or reboot if you prefer) at 03:14:07 UTC on January 19th, 2038. [0] So, that means that the remake of an OS that we call a browser is likely to be the pinnacle of computing for our lifetimes. Hopefully after the Great Reboot of 2038, the next generation will learn from our computing mistakes, but since we've never learned from those that came before us, it's highly unlikely. But at least they will have to start from scratch, so there's a chance! [0] - https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
- mch82 3y ago
  > Like a world that never got past the horse and buggy At lunch one day a colleague explained that the size of the space shuttle could be linked to the width of two horses walking on a Roman road :-) One of my favorite lunch breaks of all time.
mdellavo 3y ago
It's not an open standard but the JVM spec is publically available and intended for multiple implementations https://docs.oracle.com/javase/specs/jvms/se8/html/ https://docs.oracle.com/javase/specs/jvms/se8/html/

pjmlp 3y ago

It is incredible how with so much Java hate, the WASM folks are doing their best to replicate everything we had in 2005.

nu11ptr 3y ago
Honestly, I just think Java was ahead of its time. I hated sites with applets because they felt slow to startup and run. That problem is long gone with modern computers.
dianeb 3y ago
Sure, this fits the way software evolves on the circle of dumb. It goes something like this: What a great idea!... (a little later) Hmmm. That's a problem... (later) We need something to run apps in the browser. I wonder if WASM would work... (now) What a great idea!... Software development always goes in cycles. "Apps" were great now maybe not so much so... In the late 80s/early 90s, the CEO of ETA Systems (a supercomputer company) had a vision that by 2000, the world would be split between supercomputers and workstations. I have seen some evidence that people are considerng that once again... The Circle of Dumb is always with us in software land.
- frou_dh 3y ago
  As long as it's refining and making at least some progress then it's more of a helix than a circle
  - Y_Y 3y ago
    I see it as more of a conical spiral, like water going down a drain.
moonchrome 3y ago
Java still doesn't have value types AFAIK. Meanwhile WASM started out as no-gc continuous memory VM. Comparing WASM and JVM is like comparing a truck and a bus because they are relatively the same size, move at the same speed etc. I mean sure you can load people in trucks and cargo into buses - and both have been done with JVM (eg. people built C compilers) and WASM (people are building GCed runtimes on top of it despite lack of GC support from platform). Almost 30 years later nobody sane is running C on JVM and there were many attempts posted here over the years.

gabereiser 3y ago

I was just going to say, this road leads to OSGi...

tiffanyh 3y ago

Don't forget, a mail server will be included at some point since that always seems inevitable.

mc_woods 3y ago

> Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. You mean in a OCI image, a bit like this? - https://docs.docker.com/desktop/wasm/ https://docs.docker.com/desktop/wasm/ and then deployed using Kubernetes? - a bit like this - https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-pools https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-po...

benatkin 3y ago

The delivery of assets sounds like a job for Bindle which is already integrated to Spin, which looks to be more similar to python's WSGI than this https://www.fermyon.com/spin https://www.fermyon.com/spin https://www.fermyon.com/blog/bindle-what-is-it https://www.fermyon.com/blog/bindle-what-is-it

syrusakbary 3y ago
Bindle is one of the worst specifications of a container format I've ever seen, I would personally recommend anyone to stay away from it. No wonder they are ditching it in favor of OCI...

herdcall 3y ago

Multi language support is just one of the selling points, you didn't mention the other two: sandboxed security with explicit capabilities and high performance. E.g., I have a Web Assembly module running on the server (Fermyon) that needs explicit capabilities defined to even make a network call to a Twilio endpoint or read a local file. That means you can run a random Web Assembly module that you with confidence, just like you can typically open a random website on the browser without concern. By contast, you can't say that when running a random Java class that you don't trust.