
Mozilla announces WebAssembly System Interface, what JVM should have been - PandawanFr
https://www.theregister.co.uk/2019/03/29/mozilla_wasi_spec/
======
neilv
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 designed to scale from tiny devices to large server farms or
> CDNs...

> ..."That's how important it is. WebAssembly on the server is the future of
> computing. A standardized system interface was the missing link...

> ...But a write-once, run anywhere binary represents a worthwhile effort...

~~~
quantummkv
I am not surprised. As someone who cut his programming teeth on Java and .Net,
modern web development feels really out of touch with reality.

I really don't get why the community is hell bent on reinventing the wheel,
especially when the main defense of npm is that you don't have to reinvent the
wheel.

It's really disheartening to see that the best minds of the generation are
busy spending time to reinvent the same old things instead of trying to
improve upon the existing systems.

~~~
manigandham
.NET ecosystem is fantastic right now. .NET Core is fast and efficient,
asp.net is better, faster and more full-featured than ever, and MS is ahead of
everyone with Blazor Components that finally provide a real alternative to JS
frontend frameworks and can run either server-side or as WASM modules.

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

~~~
manigandham
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).

~~~
TimTheTinker
> Binaries can shrink dramatically once run through a linker and trimmed down
> to only used APIs.

It's worth pointing out that .NET Core has an assembly/executable generator
that can package only the .NET libraries that are actually used.

------
e1ven
Regardless of any technical merit or reasoning, one big advantage is that
Javascript/WASM is not controlled by any one large company or organization.

This provides substantial differentiation from .Net/Java/Flash/etc.

That said, this advantage risks diminishing if Google's influence continues to
grow.

~~~
dmitriid
> Javascript/WASM is not controlled by any one large company or organization

It’s disproportionally affected by Google.

~~~
vorpalhex
Given that Mozilla has done tons of WASM work, and that one of the earliest
implementors was Rust, comparing WASM to Oracle's iron fist over the JVM
doesn't seem to jive with reality...

~~~
dmitriid
I didn’t say Mozilla, I said Google.

I didn’t say iron fist, I said disproportionately affected.

~~~
BubRoss
And it isn't true, because Mozilla is very involved, and every browser engine
will have to get on board.

~~~
dmitriid
First and foremost Chrome has to get onboard. Hardly anyone cares if Mozilla
implements anything.

A few people will care if Safari does.

Edge is out if the picture and is being replaced by Chromium (aka Chrome).

On WebAssembly specifically. Here’s WebAssembly working group:
[https://www.w3.org/2000/09/dbwg/details?group=101196&order=o...](https://www.w3.org/2000/09/dbwg/details?group=101196&order=org&public=1)

I count 18 people from Google, and only one from Mozilla. The second largest
representation is from Microsoft (8 people), but their input is now
Chrome/Chromium input.

------
olliej
It's kind of true -- it's designed with a recognition that computers are real
things, and shouldn't be abstracted out in terms of a specific programming
model. The JVM approach (somewhat by design) limits the easer of interaction
with other systems.

The biggest drawback in WASM to me has alway been the memory model. While it
is memory safe, it's currently opaque to the host environment which means that
the general implementation is to over allocate address space and essentially
implement pointers as integers. That results in pointers that can't be
trivially shared between environments.

That said, I think that if I /were/ to be making an app that had plugins, or
an OS from scratch, etc I would define an interface via WASM. Screw loading
unbound untrusted code into my process. My code is 100% bug free _, I don 't
want to other people to break it.

_ This is not remotely true :D

~~~
saagarjha
How do you feel about the app extension model, i.e. loading bound semi-trusted
code into a sandboxed process and communicating via XPC?

~~~
olliej
App Extensions are a really good solution* to the same problem domain, with
the additional constraint that you have to support arbitrary compiled code,
with all the intentional or unintentional memory safety violations.

* I am biased here.

~~~
saagarjha
> I am biased here.

Haha, I'll defer to you then. But I'm still curious about this:

> you have to support arbitrary compiled code, with all the intentional or
> unintentional memory safety violations

But there are multiple barriers here, are there not? First, your code needs to
be signed (and notarized, at some point), and then at runtime the app
sandbox/entitlements/process separation ensures there's not much you _can_ do
even if you're running arbitrary code. Sure, the first "barrier" isn't
necessarily all that restrictive or thorough, but the other one should ideally
stop anything horrible?

~~~
olliej
It's not so much a problem of signed vs. unsigned code.

There's the "are you malware that's got through whatever rules exist in the
target App Store", but there's also the "is the extension code buggy".

In my experience the latter is the real killer - there are all sorts of things
an App Store review process can be used to prevent malware, but they're all
dependent on the code doing what static analysis claims it's doing - they
can't protect against terrible code -- my experience writing software has
taught me that no one rights 100% correct code, 100% time.

Historically GPU drivers have been a terrible source of bugs (it's why WebGL
has such tight restrictions on features and shader syntax) not because of
intentional malfeasance, but because you're processing arbitrary untrusted
content in a trusted environment (my understanding/belief is that the windows
driver model has pushed this out of the kernel? please confirm/deny), so
functionally forcing that into a restricted execution environment is a win.

Obviously the memory model of WASM still allows for things like use after
free, out of bounds access, etc; but at least it's not unbound into the host
address space.

~~~
saagarjha
I guess you're assuming that the platform/runtime that's doing the isolation
is close to being correct, which we both know isn't quite true ;) The only
benefit I see is that you're adding an additional level of abstraction
(namely, you're executing a vetted selection of native code rather than
arbitrary native code), which makes reaching the point where you can actually
break things harder. Was this the point you were trying to make?

~~~
olliej
The idea is to reduce the ability of the untrusted code to go wrong and
compromise the host.

Going wrong can mean “exploited by malware” through to “extension code trawls
the host process address space to provide ‘features’”

The latter of these two used to happen all the time with “haxies” on OS X.

The run on security benefit of providing a semi-virtualised environment for
third party/untrusted code is that if the VM is exploited _you_ are able to
fix and ship a fix for the VM. You can’t fix the untrusted code.

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

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

~~~
btlr
Where did you get this "Java failed" idea? Java is one of the most widely used
languages in the whole world...

~~~
otabdeveloper1
Java failed as a portable language-agnostic VM for user-facing apps.

You know, the use-case it was originally designed for. (I read the hype for
Java 1.0, I was there.)

Nobody at the time could imagine that Java would eventually become the
enterprise COBOL replacement.

~~~
cmiles74
I'm not so sure it failed. I use IntelliJ IDEA daily, people in my office use
WebStorm for Javascript development. There are Swing applications out there
that people use, admittedly the ones I've seen are mostly business software.
And of course all Android applications are leveraging Java.

It's argued that only IDEs use Java, but Java + Swing strikes me as the most
popular cross-platform language and toolkit currently in use.

~~~
vraivroo
that's only if you don't consider "web/browser" to be "cross-platform"

------
manigandham
I wonder what new standard we'll come up with 10-15 years from now that'll be
titled "What WASM should have been".

~~~
asdkhadsj
Isn't that what the goal of software should be? Solving problems with older
implementations?

Do people think WASM is not better than the JVM for streaming browser based
usage? Did it learn nothing from the JVM? The sarcasm in these threads always
confuses me.

~~~
pjmlp
Yes, because WASM is basically politics due to the refusal of other browser
vendors to adopt PNaCL, and it doesn't provide any security for memory bound
and null pointer exploits inside the sandbox.

~~~
asdkhadsj
So where were JVM targets for all my favorite languages, or any browser
support for that matter?

I'm not going to debate any points against the JVM, but all I know is that I
can compile languages I want to all browsers _today_. Why can't I do that for
the JVM?

Something must be a massive, gory failure of the JVM and/or the companies
involved with the JVM for it to be an equal to that of WASM, and yet have zero
traction for modern languages and browser targets.

~~~
pjmlp
Depends on the language I guess, I can compile Java, Kotlin, Scala, Clojure,
TCL, Python, Ruby, Common Lisp and any other one able to produce LLVM bitcode
on the JVM.

Also 86% of the mobile OS market runs on Java.

Additionally smartcards, a big portion of electricity meters, factory
automation, smart copiers, M2M gateways, Bluray Players,... run on Java.

Alongside JavaScript and .NET, it rules software development across the
corporations of the world.

Hardly a failure, only for naysayers.

------
ragerino
Kind of funny. WebAesembly is basically like a pre-installed Java Browser
Plugin.

~~~
tracker1
Without all the bugs and security holes.

~~~
mooman219
Everything was intended to be secure but no one writes perfectly secure code,
same goes for WASM. Java exposed a lot of system access (files, devices, I/O)
that you just don't have in WASM. In that aspect it's more secure, but it also
does less. If you're going to include the browser APIs, you can argue they're
just as insecure as Java given their less than stellar history.

~~~
tracker1
Name any technology that loads and executed remote content with a better track
record than browsers and JavaScript. At least anything with even 1% the
capability.

------
blitmap
I wish JS made it easier to sandbox itself with existing mechanics - like
simply unreferencing a system API. I am looking forward to this.

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

------
Animats
The JVM in the browser was supposed to be safe, too.

~~~
olliej
The underlying problem is what the threat model was - in Java/JVM a
significant amount of effort was put into addressing "what if the byte code
itself is malicious", with the core applet VM having quite a lot of power over
the system - e.g. file I/O, GPU access, etc.

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

~~~
kevingadd
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 regret letting type safety and other
features slide.

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

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

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

------
ilaksh
Is there a link to the WASI spec?

~~~
TUSF
This seems to be the current documentation:
[https://github.com/CraneStation/wasmtime/blob/master/docs/WA...](https://github.com/CraneStation/wasmtime/blob/master/docs/WASI-
documents.md)

------
newen
Why do they call it webassembly if it doesn't even have goto.

------
chubot
This previous thread covers differences between the JVM and WebAssembly:

[https://news.ycombinator.com/item?id=19502702](https://news.ycombinator.com/item?id=19502702)

tl;dr

\- JVM doesn't do enough to separate computation and I/O

\- JVM doesn't run C code very well, or it requires research-level technology
to do so (Graal). This applies to both computation and I/O -- it has a
completely different I/O interface than C programs rely on.

\- Photoshop / Word / Excel / etc. were never ported to the JVM. The browser
actually has better equivalents of them.

~~~
threeseed
That last one is really stupid.

The reason they weren't ported is because they were legacy codebases with some
code going back to the original versions including lots of assembler. It was
always going to be a monumental task to rebuild them from scratch.

~~~
chubot
That you don't have to rebuild such apps from scratch on WASM is exactly the
point.

You can compile legacy codebases in C and C++ to WASM. It was designed for
that. Doing that on the JVM requires "research-level" techniques because the
bytecode has a completely different design.

------
snazzycalynx
I see nobody's mentioned that Kotlin can compile to WebAssembly (in addition
to Java bytecode, native binaries and JS).

Kotlin is a beautiful language and hopefully WebAssembly will help it to gain
traction outside the Android world.

~~~
afiori
What Kotlin is now has no bearing on what JVM was then or even what JVM is now

------
Thermolabile
Isn't most of the work done already with LLVM intermediate representation?
Stick to POSIX (and Qt if necessary) in the code, distribute the IR with a
compiler which compiles and installs it, and job done.

~~~
0815test
There's no such thing as a single LLVM IR. It's actually a family of IR's
where the actual representation is always dependent on target architecture.

------
tus87
If you want to pull the chain on this diarrhea:

[https://github.com/stevespringett/disable-
webassembly](https://github.com/stevespringett/disable-webassembly)

~~~
dang
Please don't post name-calling dismissals of other people's work to HN. This
is in the guidelines:
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html).

The article you've linked to is much better than this and deserves a better
representation than that.

------
StevePerkins
Speaking as someone who has made their career with Java, "what the JVM ought
to have been" is marketed for server-side use from the beginning.

It was poorly suited for the browser from the earliest days, and even now the
language and runtime have evolved to make it a round peg for that square hole
no matter how WASM develops.

Yet because students and younger webdevs see it through the prism of trying to
be a browser-side solution, it taints the brand for people who lack business
application experience. Java is thought of as "insecure", even though the
OVERWHELMING majority of security patches are for the browser applet plugin,
which hasn't been widely used in twenty years and now being retired. Instead
of being " _a thing that makes large-scale business server applications more
performant, and more tenable for large teams to work on_ ", it is often seen
by newbies as " _a failed React.js alternative_ " where it comes up short.

Actual Java developers stopped thinking of it that way decades ago, but the
history unfortunately persists.

~~~
fulafel
Java in the beginning was standaline on the client side too. The web browser
plugin came post 1.0 and the pre 1.0 (Oak) target applications were more IoT,
not web

