7 ms·

ok, so I hate to be this guy and I'm going to do it anyway because it has to be said: Did they just invent Java again? Aren't they promising what Java promise

ok, so I hate to be this guy and I'm going to do it anyway because it has to be said: Did they just invent Java again? Aren't they promising what Java promised? Won't they hit the same problems that Java hits during its write-one-run-anywhere promises? I'm asking honestly - why is WebAssembly outside of the browser needed?

jzoch 8y ago
The idea of isolation that java espoused is not a bad one - it just wasnt executed well. Its not a java only idea either - see Native Client[0]. As with all things, execution and marketing matter. Java was lacking in both. [0] - https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf https://static.googleusercontent.com/media/research.google.c...
- naikrovek 8y ago
  OK, that's all correct and valid. Java still exists and is a valid deployment platform. Why is WebAssembly outside of the browser needed?
  - JeremyBanks 8y ago
    Using Oracle's Java Programming Language is an immeasurable legal liability.
    - deleted 8y ago
      [deleted]
    - naikrovek 8y ago
      There are open source and non-Oracle Java virtual machines you can buy support from if Oracle isn't your cup of tea. It's not really a legal liability either. Lawyers for companies who use Java go over those agreements with a fine tooth comb and approve them before they're signed. There are no surprises (if your attorneys aren't frauds.)
      - JeremyBanks 8y ago
        Google's was not using Oracle's virtual machine, and their attorneys were not frauds, but they've been tied up in litigation for most of a decade and are facing potentially ten billion dollars in penalties. https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google.... Java is not a responsible or ethical choice for anybody to use for any purpose.
        pjmlp 8y ago
        They just screwed Sun, created Android J++ with applause from wannabe be Google employees, and turned down the opportunity to buy Sun and own Java. They deserve what they get.
        pdpi 8y ago
        Google's case is less one of "using" Java, and more one of reimplementing it. It's an entirely different legal beast.
    - pjmlp 8y ago
      I am pretty sure IBM has a couple of patents regarding VM implementations.
  - chubot 8y ago
    Java is no longer a valid deployment platform for dynamically executing untrusted code. https://www.java.com/en/download/faq/chrome.xml https://www.java.com/en/download/faq/chrome.xml The Java Plugin for web browsers relies on the cross-platform plugin architecture NPAPI, which had been supported by all major web browsers for over a decade. Google's Chrome version 45 and above have dropped support for NPAPI, and therefore Java Plugin do not work on these browsers anymore. All the other browsers killed it as well. There's probably some way you can do it outside the browser, but I've never seen it used. Was it called Java WebStart or something? I think it's because the sandbox had too many holes, and it was large and clunky. It didn't integrate well with the browser. Java is obviously still extremely popular, but it's used in trusted contexts, like on the server, or "semi-trusted" contexts, like the Android app store. Although that is a different JVM which is probably easier to secure. And in that case there has to be a manual review process before allowing arbitrary code to execute (which is imperfect, but better than nothing.)
    - AnIdiotOnTheNet 8y ago
      It remains to be seen if WASI will actually have fewer holes in its sandbox. Fundamentally it is not different.
      - chubot 8y ago
        I think an important difference is that in the new architecture, there's a separation between WASM and WASI. That is, computation and I/O are treated separately. It's more like capability-based security. WASM modules have no capabilities except the ones explicitly injected when you instantiate it. As far as I understand, the JVM wasn't as rigorous about this, although to be fair I don't know all the details. So WASI could still have a lot of holes, but WASM would survive and be useful. And then maybe someone else could come around and do it in a different, better way. That hasn't happened with Java.
    - naikrovek 8y ago
      Java inside the browser doesn't exist. That's fine. That's not what I'm talking about or making comparisons to. Java runs just fine outside of the browser. You don't even need a browser installed to run Java applications. Javascript and WASM run fine inside the browser, and that's not what I'm talking about or making comparisons to. I'm talking about running WASM binaries outside of the browser. Similar to how Java runs outside of the browser. Very similar, actually. Java needs a runtime to be installed or available, so will WASI. Java is a write-once-run-anywhere type of platform, so is WASI. Why does WASI need to exist if Java already exists for the intended uses?
  - RivieraKid 8y ago
    Well, the second paragraph in the article gives you the answer: > Why: Developers are starting to push WebAssembly beyond the browser, because it provides a fast, scalable, secure way to run the same code across all machines. It allows you to use the same code both inside and outside of the browser. For example, Figma might use it, they already have a web app and a regular app, both using WebAssembly, so WASI would perhaps simplify their code or allow them to add more native integration to their app. Making a product that's a slight variation of an existing product is often enough to gain significant market share. For example, was Chrome needed when there was Firefox? Was Figma or Adobe XD needed when there was Sketch? Is Rollup or Parcel needed when there is Webpack and Gulp? This could go forever. I mean, should Java be the only universal deployment platform?
  - sitkack 8y ago
    Signed types and a proper cross language target. There is very little technical difference between the two, esp now that GraalVM has shipped. WASM is now the portable executable standard. https://www.graalvm.org/ https://www.graalvm.org/
    - smolder 8y ago
      I'm sure this was meant to say unsigned types - Java only uses signed types.
      - sitkack 8y ago
        Correct, my mistake. unsigned types.
    - imtringued 8y ago
      So you're saying the JVM wasn't good enough so they had to make a better one? Why does the HN crowd constantly compare WASM with the "obsolete" JVM, when even the creator admits that it is not adequate?
      - sitkack 8y ago
        JVM could have been WASM but they made some unfortunate design decisions. They started as a target only for Java, GC, signed types. WASM started from the bottom, floats and ints (signed and unsigned) with plans to add GC, threads etc later. It isn’t that the JVM is bad, it is that it isn’t the universal compilation target that WASM is. Remember folks getting excited about LLVMIR, Bitcode? WASM is this but with a clean sandbox and minimal tractable semantics. The JVM is awesome, esp with Graalvm and Truffle. WASM is the next evolutionary step.
ryanschneider 8y ago
> why is WebAssembly outside of the browser needed? It's arguably a better standard runtime than Java, for certain use cases. You don't see modern compilers targeting the JVM as an output target, but you do see them targeting WASM, there's probably good reason(s) for that (both technical and political/legal). Furthermore, my understanding of WASI is that it allows standardization of _multiple_ runtimes, each domain specific. For example, Functions as a Service. Currently AWS Lambda requires building a blob specially for them targeting their APIs and ABI. But what if Fastly, Fly.io, and the other "App CDN" FaaS providers come up with their own standard for "syscalls" for a WebASM-FaaS-1.0 spec? As a really bad example, the syscalls could be: - 1 GET URL - 2 POST URL - 3 Cache Read - 4 Cache Write Meanwhile, in a totally different ecosystem, Ethereum can publish their own WASI for eWASM, where the syscalls are: - 1 Storage Read - 2 Storage Write - 3 Contract Call Again, these are bad/contrived examples, the real syscalls would be better thought out than an HN comment, but the point is that you have two totally different runtimes, running is totally different places (on a CDN server, vs. inside an Ethereum node), both using the same tech stack w/ different "system interfaces" abstracting away what things your WASM code should have access to at runtime. Any language that has a compiler that targets WASM can be used in either case. Furthermore, the barrier for entry as a syscall provider becomes much simpler too! If I want to make a local sandbox for FaaS testing, I just need to implement the syscalls from WebASM-FaaS-1.0 using local stubs, now I can test my FaaS locally. Way easier than the months/years probably spend reverse engineering the lambda environment for local testing. And if I come up with a novel solution for servicing one of those syscalls, hey, maybe I'll take my own stab at being a FaaS CDN. :) Likewise for Ethereum and eWASM. Maybe I want to make a local test environment sandbox. Instead of re-implementing the EVM I "just" need to implement those syscalls outlined in the eWASM WASI spec (if such a spec existed). So now maybe light clients ship those syscalls over the wire somehow, and don't need to keep gigabytes of block chain data locally anymore. edits: minor formatting
- naikrovek 8y ago
  OK you answered a few of my questions and I still don't see why WASM is a requirement for any of this to happen. No matter what language I use, no matter what platform I deploy to, if I want to interact with a service or with infrastructure, I'm going to have to use the provided API(s), WASM included. If I deploy a pre-compiled binary to an AWS Lambda and an Azure Function, and it works on both, it's because I had to have that in mind when I wrote that software. Will that not be true for a runnable WASM binary? It sure seems like it would be true that I would need to detect which platform I'm running on and then execute the proper stuff for the detected platform. If all APIs are going to be compatible with each other, so that, say, storing a file uses the same API call no matter what system or platform you're on (never going to happen; bear with me) implementing that in WASM outside of the browser does not suddenly make it possible. This is an opinion, and on HN this is likely to be a very unpopular opinion. I don't expect anyone to adopt this opinion, nor do I expect to sway anyone's thought with this opinion. This really (really, really, really) feels like JavaScript/web people wanting to do things outside of the browser, with performance better than JavaScript alone can provide, and then, rather than simply using an existing language and runtime, deciding that the best route forward is to pave their own road to this destination with web technologies. This does not feel like the best route to take if you want to write software that performs well outside of a browser. There are lots of other languages, runtimes, and platforms, that allow this today. And the web is a bag of chaos: I can't even get a consistent design or UI language across major websites, today. Buttons sometimes look like links, links sometimes look like menus, and buttons sometimes look like any of those, but somehow WASM outside of the browser is something everyone (except me) can agree on? I'm skeptical that this is a good idea for anything serious. Just like there are implementation problems with Java, there are going to be implementation problems with these runtimes that every platform is going to need in order to run this code, now. There are going to be many security concerns because (warning: incoming opinion) nearly all developers are terrible at thinking about preventing security vulnerabilities. Those same developers are usually OK when it comes to fixing them, and terrible at thinking about vulnerability prevention.
deleted 8y ago
[deleted]
gwbas1c 8y ago
Targeting the JVM (or the CLR) requires that your language work nicely in the Java (or C#) memory model. This basically means your language needs to work nicely with stop the world garbage collection. (And yes, I know that modern garbage collectors aren't really stop the world, but the tradeoffs are still there.)
- pjmlp 8y ago
  CLR was designed for multi-language since the beginning. Go dig one of those .NET 1.0 SDK release CDs from 2002, plenty of sample languages on it.
  - gwbas1c 8y ago
    I know that. The problem is that the CLR comes with the the C# memory model and garbage collection. If you don't want that, then what's the point of the CLR? You can't use most of the .Net API without objects and garbage collection. That basically rules out any kind of real-time application. The more modern garbage collectors allow soft real time applications, but you still can't do things like use the CLR to run an airplane. If you want to use the CLR for a real-time application, you basically have to replace most of the .Net API with a completely pointer-based version, and consider implementing your own real-time memory management model. At that point, you might as well target your language to compile natively and use standard libraries in the operating system.
    - pjmlp 8y ago
      The CLR was designed to support C and C++ as well, apparently new generations don't have a proper clue what CLR is all about. Also contrary to WASM, there are real hardware devices actually shipping stripped down versions of it. And if real time is a concern, then not using a real time OS is already the big first mistake, there is nothing here for WASM to prove, only to catch up with existing battle tested solutions.
twic 8y ago
> Did they just invent Java again? No. Like Java, they just reinvented DEL again: https://tools.ietf.org/html/rfc5 https://tools.ietf.org/html/rfc5

jzoch 8y ago

The idea of isolation that java espoused is not a bad one - it just wasnt executed well. Its not a java only idea either - see Native Client[0]. As with all things, execution and marketing matter. Java was lacking in both. [0] - https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/34913.pdf https://static.googleusercontent.com/media/research.google.c...

naikrovek 8y ago
OK, that's all correct and valid. Java still exists and is a valid deployment platform. Why is WebAssembly outside of the browser needed?
- JeremyBanks 8y ago
  Using Oracle's Java Programming Language is an immeasurable legal liability.
  - deleted 8y ago
    [deleted]
  - naikrovek 8y ago
    There are open source and non-Oracle Java virtual machines you can buy support from if Oracle isn't your cup of tea. It's not really a legal liability either. Lawyers for companies who use Java go over those agreements with a fine tooth comb and approve them before they're signed. There are no surprises (if your attorneys aren't frauds.)
    - JeremyBanks 8y ago
      Google's was not using Oracle's virtual machine, and their attorneys were not frauds, but they've been tied up in litigation for most of a decade and are facing potentially ten billion dollars in penalties. https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google,_Inc https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google.... Java is not a responsible or ethical choice for anybody to use for any purpose.
      - pjmlp 8y ago
        They just screwed Sun, created Android J++ with applause from wannabe be Google employees, and turned down the opportunity to buy Sun and own Java. They deserve what they get.
      - pdpi 8y ago
        Google's case is less one of "using" Java, and more one of reimplementing it. It's an entirely different legal beast.
  - pjmlp 8y ago
    I am pretty sure IBM has a couple of patents regarding VM implementations.
- chubot 8y ago
  Java is no longer a valid deployment platform for dynamically executing untrusted code. https://www.java.com/en/download/faq/chrome.xml https://www.java.com/en/download/faq/chrome.xml The Java Plugin for web browsers relies on the cross-platform plugin architecture NPAPI, which had been supported by all major web browsers for over a decade. Google's Chrome version 45 and above have dropped support for NPAPI, and therefore Java Plugin do not work on these browsers anymore. All the other browsers killed it as well. There's probably some way you can do it outside the browser, but I've never seen it used. Was it called Java WebStart or something? I think it's because the sandbox had too many holes, and it was large and clunky. It didn't integrate well with the browser. Java is obviously still extremely popular, but it's used in trusted contexts, like on the server, or "semi-trusted" contexts, like the Android app store. Although that is a different JVM which is probably easier to secure. And in that case there has to be a manual review process before allowing arbitrary code to execute (which is imperfect, but better than nothing.)
  - AnIdiotOnTheNet 8y ago
    It remains to be seen if WASI will actually have fewer holes in its sandbox. Fundamentally it is not different.
    - chubot 8y ago
      I think an important difference is that in the new architecture, there's a separation between WASM and WASI. That is, computation and I/O are treated separately. It's more like capability-based security. WASM modules have no capabilities except the ones explicitly injected when you instantiate it. As far as I understand, the JVM wasn't as rigorous about this, although to be fair I don't know all the details. So WASI could still have a lot of holes, but WASM would survive and be useful. And then maybe someone else could come around and do it in a different, better way. That hasn't happened with Java.
  - naikrovek 8y ago
    Java inside the browser doesn't exist. That's fine. That's not what I'm talking about or making comparisons to. Java runs just fine outside of the browser. You don't even need a browser installed to run Java applications. Javascript and WASM run fine inside the browser, and that's not what I'm talking about or making comparisons to. I'm talking about running WASM binaries outside of the browser. Similar to how Java runs outside of the browser. Very similar, actually. Java needs a runtime to be installed or available, so will WASI. Java is a write-once-run-anywhere type of platform, so is WASI. Why does WASI need to exist if Java already exists for the intended uses?
- RivieraKid 8y ago
  Well, the second paragraph in the article gives you the answer: > Why: Developers are starting to push WebAssembly beyond the browser, because it provides a fast, scalable, secure way to run the same code across all machines. It allows you to use the same code both inside and outside of the browser. For example, Figma might use it, they already have a web app and a regular app, both using WebAssembly, so WASI would perhaps simplify their code or allow them to add more native integration to their app. Making a product that's a slight variation of an existing product is often enough to gain significant market share. For example, was Chrome needed when there was Firefox? Was Figma or Adobe XD needed when there was Sketch? Is Rollup or Parcel needed when there is Webpack and Gulp? This could go forever. I mean, should Java be the only universal deployment platform?
- sitkack 8y ago
  Signed types and a proper cross language target. There is very little technical difference between the two, esp now that GraalVM has shipped. WASM is now the portable executable standard. https://www.graalvm.org/ https://www.graalvm.org/
  - smolder 8y ago
    I'm sure this was meant to say unsigned types - Java only uses signed types.
    - sitkack 8y ago
      Correct, my mistake. unsigned types.
  - imtringued 8y ago
    So you're saying the JVM wasn't good enough so they had to make a better one? Why does the HN crowd constantly compare WASM with the "obsolete" JVM, when even the creator admits that it is not adequate?
    - sitkack 8y ago
      JVM could have been WASM but they made some unfortunate design decisions. They started as a target only for Java, GC, signed types. WASM started from the bottom, floats and ints (signed and unsigned) with plans to add GC, threads etc later. It isn’t that the JVM is bad, it is that it isn’t the universal compilation target that WASM is. Remember folks getting excited about LLVMIR, Bitcode? WASM is this but with a clean sandbox and minimal tractable semantics. The JVM is awesome, esp with Graalvm and Truffle. WASM is the next evolutionary step.

ryanschneider 8y ago

> why is WebAssembly outside of the browser needed? It's arguably a better standard runtime than Java, for certain use cases. You don't see modern compilers targeting the JVM as an output target, but you do see them targeting WASM, there's probably good reason(s) for that (both technical and political/legal). Furthermore, my understanding of WASI is that it allows standardization of _multiple_ runtimes, each domain specific. For example, Functions as a Service. Currently AWS Lambda requires building a blob specially for them targeting their APIs and ABI. But what if Fastly, Fly.io, and the other "App CDN" FaaS providers come up with their own standard for "syscalls" for a WebASM-FaaS-1.0 spec? As a really bad example, the syscalls could be: - 1 GET URL - 2 POST URL - 3 Cache Read - 4 Cache Write Meanwhile, in a totally different ecosystem, Ethereum can publish their own WASI for eWASM, where the syscalls are: - 1 Storage Read - 2 Storage Write - 3 Contract Call Again, these are bad/contrived examples, the real syscalls would be better thought out than an HN comment, but the point is that you have two totally different runtimes, running is totally different places (on a CDN server, vs. inside an Ethereum node), both using the same tech stack w/ different "system interfaces" abstracting away what things your WASM code should have access to at runtime. Any language that has a compiler that targets WASM can be used in either case. Furthermore, the barrier for entry as a syscall provider becomes much simpler too! If I want to make a local sandbox for FaaS testing, I just need to implement the syscalls from WebASM-FaaS-1.0 using local stubs, now I can test my FaaS locally. Way easier than the months/years probably spend reverse engineering the lambda environment for local testing. And if I come up with a novel solution for servicing one of those syscalls, hey, maybe I'll take my own stab at being a FaaS CDN. :) Likewise for Ethereum and eWASM. Maybe I want to make a local test environment sandbox. Instead of re-implementing the EVM I "just" need to implement those syscalls outlined in the eWASM WASI spec (if such a spec existed). So now maybe light clients ship those syscalls over the wire somehow, and don't need to keep gigabytes of block chain data locally anymore. edits: minor formatting

naikrovek 8y ago
OK you answered a few of my questions and I still don't see why WASM is a requirement for any of this to happen. No matter what language I use, no matter what platform I deploy to, if I want to interact with a service or with infrastructure, I'm going to have to use the provided API(s), WASM included. If I deploy a pre-compiled binary to an AWS Lambda and an Azure Function, and it works on both, it's because I had to have that in mind when I wrote that software. Will that not be true for a runnable WASM binary? It sure seems like it would be true that I would need to detect which platform I'm running on and then execute the proper stuff for the detected platform. If all APIs are going to be compatible with each other, so that, say, storing a file uses the same API call no matter what system or platform you're on (never going to happen; bear with me) implementing that in WASM outside of the browser does not suddenly make it possible. This is an opinion, and on HN this is likely to be a very unpopular opinion. I don't expect anyone to adopt this opinion, nor do I expect to sway anyone's thought with this opinion. This really (really, really, really) feels like JavaScript/web people wanting to do things outside of the browser, with performance better than JavaScript alone can provide, and then, rather than simply using an existing language and runtime, deciding that the best route forward is to pave their own road to this destination with web technologies. This does not feel like the best route to take if you want to write software that performs well outside of a browser. There are lots of other languages, runtimes, and platforms, that allow this today. And the web is a bag of chaos: I can't even get a consistent design or UI language across major websites, today. Buttons sometimes look like links, links sometimes look like menus, and buttons sometimes look like any of those, but somehow WASM outside of the browser is something everyone (except me) can agree on? I'm skeptical that this is a good idea for anything serious. Just like there are implementation problems with Java, there are going to be implementation problems with these runtimes that every platform is going to need in order to run this code, now. There are going to be many security concerns because (warning: incoming opinion) nearly all developers are terrible at thinking about preventing security vulnerabilities. Those same developers are usually OK when it comes to fixing them, and terrible at thinking about vulnerability prevention.

deleted 8y ago

[deleted]

gwbas1c 8y ago

Targeting the JVM (or the CLR) requires that your language work nicely in the Java (or C#) memory model. This basically means your language needs to work nicely with stop the world garbage collection. (And yes, I know that modern garbage collectors aren't really stop the world, but the tradeoffs are still there.)

pjmlp 8y ago
CLR was designed for multi-language since the beginning. Go dig one of those .NET 1.0 SDK release CDs from 2002, plenty of sample languages on it.
- gwbas1c 8y ago
  I know that. The problem is that the CLR comes with the the C# memory model and garbage collection. If you don't want that, then what's the point of the CLR? You can't use most of the .Net API without objects and garbage collection. That basically rules out any kind of real-time application. The more modern garbage collectors allow soft real time applications, but you still can't do things like use the CLR to run an airplane. If you want to use the CLR for a real-time application, you basically have to replace most of the .Net API with a completely pointer-based version, and consider implementing your own real-time memory management model. At that point, you might as well target your language to compile natively and use standard libraries in the operating system.
  - pjmlp 8y ago
    The CLR was designed to support C and C++ as well, apparently new generations don't have a proper clue what CLR is all about. Also contrary to WASM, there are real hardware devices actually shipping stripped down versions of it. And if real time is a concern, then not using a real time OS is already the big first mistake, there is nothing here for WASM to prove, only to catch up with existing battle tested solutions.

twic 8y ago

> Did they just invent Java again? No. Like Java, they just reinvented DEL again: https://tools.ietf.org/html/rfc5 https://tools.ietf.org/html/rfc5