Mozilla announces WebAssembly System Interface, what JVM should have been • Hacker News Board

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#91

Post by cmiles74 » Mon, Apr 22, 2019, 2:04 PM UTC

The quotes from the Web Assembly team at Mozilla and Solomon Hykes read like these people are suffering from some kind of late 1990s amnesia. Till Schneidereit is saying exactly the same thing Sun said when Java was announced. Acting like they are breaking new ground strikes me as unhelpful and it's not clear to me how it will help the cause. Maybe WebAssembly will enjoy more success than Java, I truly hope that it does.

IMHO, the success of these products has very little to do with how good they might be technically. It's all about sales and marketing and, eventually, politics. Perhaps that's where the motivation to re-write recent history is coming from.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#92

Post by asdkhadsj » Mon, Apr 22, 2019, 2:05 PM UTC

that_jojo wrote: post #85

asdkhadsj wrote: post #75

Earlier quoted context omitted.

I'm so often confused by these comments. Are you saying that we could stick a JVM in the browser and ship Java applets around to be progressively/streaming loaded and executed in browser? I don't know much about the JVM but it seems the goal of WASM and the JVM were quite different, no? And yes, WASI has overlap with JVM, but if WASM catches on and people like it, how does WASI make any less sense? Are you advocating…

> Are you saying that we could stick a JVM in the browser More or less. I mean, that used to be a thing you know. > the goal of WASM and the JVM were quite different WASM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems JVM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems

> More or less. I mean, that used to be a thing you know.

I did not know Java applets can be stream loaded (ie, optimized for the web).

> WASM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems

Not at all.. at least, not in my view. WASM is optimized for platform issues specific to the web. That is to say, how it behaves on load is the first priority.

I never got that impression from the JVM. If you say it is, then it seems to be a failure in marketing of the JVM or something.

Since you seem to feel WASM is a waste, what are your thoughts on the failure of the JVM? Ie, why don't I have Go and Rust compile targets for the JVM, with JVM browser code running my JVM targets and etc?

If JVM truly does have all of these WASM-web oriented features then it is an impressive failure on JVMs part. Quite curious

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#93

Post by khc » Mon, Apr 22, 2019, 2:05 PM UTC

quantummkv wrote: post #62

avian wrote: post #58

Earlier quoted context omitted.

I often wonder why this is the fact in software development and not nearly much so in other fields. Isn't the point of education that each generation doesn't have to learn past mistakes by repeating them? Do computer science curricula not include enough historical perspective? I feel like other fields of engineering don't have such a dismissive approach to their own pasts. Show an electrical engineering class an old…

> Do computer science curricula not include enough historical perspective? Anecdotally speaking, the average web developer does not have any formal computer science education. Most are self taught or attend a bootcamp or two at most. They have excellent vocational skills, but little knowledge of anything in computing outside of their narrow path of learning.

People who develop webassembly are not your average web developers

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#94

Post by analognoise » Mon, Apr 22, 2019, 2:10 PM UTC

ksec wrote: post #46

neilv wrote: post #4

No slight against WASM (which I've promoted), but early Java people would be well-advised to sit down somewhere they can sob in privacy, before reading this article: > ...you can't run Java code in a browser without a plugin... > ...WASM, being memory safe and tuned for validation, also has security advantages over Java applets... > ...explained the difference between WebAssembly and Java thus: "WebAssembly has been…

The only difference is that WASM will be available ( I assume ) in most PC Chrome Browser within 2 - 3 years of releasing, that is 800M+ assuming Chrome with stable market shares. Along with Android, that is a potential of 2-3B devices, assuming stable upgrade cycle and shipment. That is more penetration than Java could ever get on Desktop and Mobile. Although Java is actually doing ok in embedded space, I am not ent…

Maybe my sarcasm detector is failing, but:

Java is the most used programming language in the world (https://www.tiobe.com/tiobe-index/)

It not only powers all kinds of desktop things, it is foundational to Android, which currently powers ~85% of all mobile devices.

How can you get more penetration than "most used programming language" and "foundational to the largest mobile OS"? I mean there isn't even a category that fully encompasses the degree of dominance of Java. The next step, I assume, would be to rename "Programming" (all of it) to "Java".

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#95

Post by analognoise » Mon, Apr 22, 2019, 2:13 PM UTC

that_jojo wrote: post #88

TimTheTinker wrote: post #73

Earlier quoted context omitted.

> Reminds me of client-side JS frameworks. Or Electron apps. Even big framework web apps on a core 2 duo running old Firefox, that is nowhere as bad as early Java trying to run something as a web applet. I remember staring at that crazy Java applet load spinner and hating Java, and this was already in the early 2000s (on the first white iBook running Mac OS 9). It would have been much worse 7 years earlier. It was re…

Thanks for teaching me something totally unrelated on accident today. I was under the impression that all of the post-clamshell iBooks were OSX-only and had to check everymac. Now I'm slightly wiser on a topic that no one gives a shit about.

"Now I'm slightly wiser on a topic that no one gives a shit about." - I'm taking this quote and integrating it into my life.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#96

Post by otabdeveloper1 » Mon, Apr 22, 2019, 2:15 PM UTC

cmiles74 wrote: post #91

The quotes from the Web Assembly team at Mozilla and Solomon Hykes read like these people are suffering from some kind of late 1990s amnesia. Till Schneidereit is saying exactly the same thing Sun said when Java was announced. Acting like they are breaking new ground strikes me as unhelpful and it's not clear to me how it will help the cause. Maybe WebAssembly will enjoy more success than Java, I truly hope that it d…

> It's all about sales and marketing and, eventually, politics.

Not in this case. Java failed because it sucked from a technical point of view. It traded better 'OO purity' in exchange for worse security, portability and performance.

The end result is that users got something that was slower and buggier for no gain.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#97

Post by nwah1 » Mon, Apr 22, 2019, 2:18 PM UTC

davidhyde wrote: post #50

nwah1 wrote: post #35

Earlier quoted context omitted.

I agree largely from a development perspective, but the client-side javascript frameworks are ultimately more performant, particularly on mobile, and are not as bad as they used to be. Neither server-side nor WASM are ideal for mobile devices. Downloading many megabytes of .NET dependencies for a WASM app is obscene compared to like 30 kilobytes for React.

> “30 kilobytes for React” This is just not even close to being true.

The compressed size is 31 kb, and other frameworks are smaller.

https://gist.github.com/Restuta/cda69e50a853aa64912d

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#98

Post by otabdeveloper1 » Mon, Apr 22, 2019, 2:21 PM UTC

asdkhadsj wrote: post #92

that_jojo wrote: post #85

Earlier quoted context omitted.

> Are you saying that we could stick a JVM in the browser More or less. I mean, that used to be a thing you know. > the goal of WASM and the JVM were quite different WASM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems JVM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems

> More or less. I mean, that used to be a thing you know. I did not know Java applets can be stream loaded (ie, optimized for the web). > WASM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems Not at all.. at least, not in my view. WASM is optimized for platform issues specific to the web. That is to say, how it behaves on load is the first priority. I never got that impression from…

> ...why don't I have Go and Rust compile targets for the JVM, with JVM browser code running my JVM targets and etc?

The JVM is not a true VM. It's heavily coupled to the Java object model and the Java GC.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#99

Post by otabdeveloper1 » Mon, Apr 22, 2019, 2:29 PM UTC

kevingadd wrote: post #26

pjmlp wrote: post #17

Earlier quoted context omitted.

Actually only when one did not bothered to spend any effort with Security Managers, Classloaders separation and JAAS. All the tools were there. WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking.

In general the groups doing standardization for browser APIs and runtimes don't seem to care much about whether web applications are compromised, only whether the browser or host platform are compromised. It's reasonable for the latter two to be priorities, but when we're talking about huge gmail-tier applications running unsafe C in a sandbox that have access to All Your Important Data, we're going to massively regr…

> ...we're going to massively regret letting type safety and other features slide.

PHP is memory safe, and yet is a larger source of data breaches and security bugs than C by (rough guess) an order of magnitude.

C is not the bogeyman you're looking for.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#100

Post by burnte » Mon, Apr 22, 2019, 2:45 PM UTC

phkahler wrote: post #72

neilv wrote: post #4

No slight against WASM (which I've promoted), but early Java people would be well-advised to sit down somewhere they can sob in privacy, before reading this article: > ...you can't run Java code in a browser without a plugin... > ...WASM, being memory safe and tuned for validation, also has security advantages over Java applets... > ...explained the difference between WebAssembly and Java thus: "WebAssembly has been…

From TFA: >> Mozilla this week announced a project called WASI (WebAssembly System Interface) to standardize how WebAssembly code interacts with operating systems. This is just another implementation of holes that allow web sites access to the rest of your system. It really is supposed to be the operating systems job to manage resources and what can be accessed. The problem is this functionality keeps getting re-impl…

> This is just another implementation of holes that allow web sites access to the rest of your system.

Well, unlike systems designed in the 90s, it's designed for the modern "everything-is-a-threat" mindset rather than the optimism of the 90s that everything would be safe.