3 ms·
>So there's no fundamental difference between WASM and JVM bytecode. There's only practical difference: WASM proved to be secure and JVM did not. There's more
by jasode 2y ago
>So there's no fundamental difference between WASM and JVM bytecode. There's only practical difference: WASM proved to be secure and JVM did not.
There's more to it than just the sandbox security model. The JVM bytecode doesn't have pointers which has significant performance ramifications for any language with native pointers. This limitation was one of the reasons why the JVM was never a serious compilation target platform for low-level languages like C/C++.
E.g. Adobe compiled their Photoshop C++ code to WASM but not to the JVM to run in a Java JRE nor the Java web applet. Sure, one can twist a Java byte array to act as a flat address space and then "emulate" pointers to C/C++ but this extra layer of indirection which reduces performance wasn't something software companies with C/C++ codebases were interested in. Even though the JVM was advertised as "WORA Write-Once-Run-Anywhere", commercial software companies never deployed their C/C++ apps to the JVM.
In contrast, the motivation for asm.js (predecessor to WASM) was to act as a reasonable and realistic compilation target for C/C++. (https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-nightly/#:~:text=start%20compiling%20C/C%2B%2B%20code https://blog.mozilla.org/luke/2013/03/21/asm-js-in-firefox-n....)
So the WASM-vs-JVM story can't be simplified to "just security" or "just politics". There were actual different technical choices made in the WASM bytecode architecture to enable lower-level languages like C/C++. That's not to say the Sun Java team's technical choices for the JVM bytecode were "wrong"; they just used different assumptions for a different world.
- adamc 2y agoAlso, the start-up time for the JVM made running applets very sluggish. Java quickly became a synonym for "slow".
- tromp 2y agoLack of 64-bit ints didn't help either...
- kaba0 2y agoYou can’t just compare across decades of software and hardware development. Even downloading native binaries would have been sluggish, as the download would have been slow with those download speeds.
- adamc 2y agoBut web pages were not so sluggish, hence people chose them over using applets.
- kaba0 2y agoWeb pages at the time could at most <blink>, its interactivity was extremely limited compared to what we have know. Meanwhile a java applet could include a full-blown IDE/CAD/what have you
- adamc 2y agoWell, web pages could submit forms, which was the main thing. I remember working on apps where we went with web pages because applets were too slow, regardless of the features we gave up. Images were generated on the back end instead, for example.
- fastball 2y agoIsn't the cold-start for the JVM still relatively slow, even in [current year]? EDIT: seems like yes[1], at least where AWS Lambda is concerned. [1] https://filia-aleks.medium.com/aws-lambda-battle-2021-performance-comparison-for-all-languages-c1b441005fd1 https://filia-aleks.medium.com/aws-lambda-battle-2021-perfor...
- nobleach 2y agoI have a couple Quarkus apps that I've run in Lambdas that start in about a second. This is without using GraalVM too! Good enough for what I was doing (taking a list of file names, finding them in an S3 bucket and zipping them into a single payload)
- deleted 2y ago[deleted]