Live data from Hacker News

Mozilla announces WebAssembly System Interface, what JVM should have been

theregister.co.uk

151–156 of 156 posts

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

#151

Earlier quoted context omitted.

> ...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.

PHP may be memory safe but the shitload of poorly written C extensions enabled by default on all hosts that shipped with the distribution from 1995 to 2010 sure as hell weren't.

C extensions wasn't the part of PHP that broke the amateur Internet, SQL injections were.

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

#152
Java is a language backed by the JVM it tried to do two things:

Be _the_ language (Java)

Be _the_ platform (JVM)

Wasm is a compilation target, it's better to compare it to the JVM than Java. The thing that has me excited is that _every_ language will be write once run everywhere not just some new and unproven language (like Java was at the time).

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

#153
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.

It won't be megabytes, that's only in the experimental phase. Binaries can shrink dramatically once run through a linker and trimmed down to only used APIs. As far as performant, I agree it wont matter in most trivial interactions but large datasets with computations already see an impact (for example we have million row datatables to show sometimes).

Rust-based WASM front-end libraries will likely be small and also high performance. Unfortunately, all of the existing ones are highly experimental right now.

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

#154
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.

And a lot of times, these are the people writing confidently on the internet about web development. Problem with programming is most of the people in the community are amateurs and they communicate via the internet. And on the internet, no one knows you are dumb.

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

#156
post #49

Earlier quoted context omitted.

>"WebAssembly has been designed to scale from tiny devices to large server farms or CDNs..." What's ironic is that the "tiny devices" and even "high end professional desktop workstation and server devices" that Java was originally designed to run on when it was started in 1990 were MUCH tinier than the devices considered "tiny" today. How many more times faster is a typical smartphone today (Raspberry Pi 3: 2,451 MIP…

Forget full computers, an official Java subset even runs on every GSM SIM card. It is incredible! https://en.m.wikipedia.org/wiki/Java_Card

But writing Javacard for ICCs is like writing another language and ecosystem entirely. The syntax is familiar but there the comparison kind of ends.
Post reply on HN