Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Standardizing WASI: A system interface to run WebAssembly outside the web

hacks.mozilla.org

Post reply on HN
Print view View original

141–150 of 238 posts

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#141

Post by pjmlp »

gwbas1c wrote: post #93
naikrovek wrote: post #33

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?

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

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.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#142

Post by chubot »

AnIdiotOnTheNet wrote: post #85
chubot wrote: post #60

Earlier quoted context omitted.

Java is no longer a valid deployment platform for dynamically executing untrusted code. 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…

It remains to be seen if WASI will actually have fewer holes in its sandbox. Fundamentally it is not different.

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.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#144

Post by Hydraulix989 »

timClicks wrote: post #128
Teknoman117 wrote: post #123

Earlier quoted context omitted.

... 20 years later JVM, CLR, and WASM suck balls. People have been breaking the sandbox for the better part of a decade. We're hoping Cool New Thing™ starts over from scratch and does things right this time around.

But isn't that the point? We should be getting better at building software over time. Sometimes that means restarting.

UNIX is a good counter-argument.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#145

Post by pjmlp »

AnIdiotOnTheNet wrote: post #86
Crinus wrote: post #59

Earlier quoted context omitted.

POSIX != C and from what i understand from the official docs, they already have a (musl derived, even) C library.

The C stdlib is so married to POSIX they may as well be the same thing.

Actually no, go read ISO C and compare it with POSIX expectations.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#146

Post by AnIdiotOnTheNet »

Touche wrote: post #119
AnIdiotOnTheNet wrote: post #64

Earlier quoted context omitted.

We have had dozens of cross-platform application APIs running in VM sandboxes, yet the browser is intent on slowly reinventing them anyway.

Eh, I'm not trying to discourage you from building cool apps on top of WASI. I just hope you understand what you're up against. And most of it is not technical; you've got to convince Apple to include a WASI runtime on iOS (among others).

Just like any new feature added to the web standard requires that Apple actually implement it in Safari, right?

I'm not really pro-WASI so much as I am against the idea that the browser is a good application platform.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#147

Post by JeremyBanks »

Hydraulix989 wrote: post #144
timClicks wrote: post #128

Earlier quoted context omitted.

But isn't that the point? We should be getting better at building software over time. Sometimes that means restarting.

UNIX is a good counter-argument.

UNIX is thoroughly obsolete. Its continued use is from inetia; people rarely need anything but a tiny subset of its capabilities, for which there are more simpler alternatives every day.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#148

Post by nutjob2 »

emerongi wrote: post #110
mhh__ wrote: post #102

Earlier quoted context omitted.

Does it matter? I don't really see the issue with competing standards if the standards are open: The "best" (for some definition of best) should win out eventually. Anything other than Electron if it comes to it

We could re-implement C as well, but is it sensible if we already have C? If someone could explain the difference between WASI and JVM the way you can explain the difference between C, C++ or Rust, it would help a lot. If there is no such explanation, I think we should really question what is being accomplished here. As it stands currently, WebAssembly seems to integrate nicely with browsers, whereas JVM works nicely…

If something, be it a language or a VM is not up to scratch, it would seem to be a good idea to reimplement it. Would you propose just sticking with the mediocre present instead?

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#149

Post by vardump »

kllrnohj wrote: post #137
vardump wrote: post #109

Earlier quoted context omitted.

Because you want to be able to dynamically load semi-trusted code on a microcontroller without MMU and run it without having to worry it could crash the whole thing?

Do you have an actual example of such a thing? I'm struggling to come up with a case of multiple independent mini-programs in such a microcontroller that needs, or even benefits, from that level of fault isolation.

Rapid prototyping, replacement for a scripting facility, diagnostics filtering & output, a platform for "apps" for a small IoT type devices and just the ability to run the same plugin anywhere you please.

It can be an enabler for new innovations. Even if it runs 2-10x slower than native code.

And what if the answer was just: just because I can? That's how a lot in our industry got started.

Re: Standardizing WASI: A system interface to run WebAssembly outside the web

#150

Post by chubot »

naikrovek wrote: post #90
chubot wrote: post #60

Earlier quoted context omitted.

Java is no longer a valid deployment platform for dynamically executing untrusted code. 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…

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 r…

> Why does WASI need to exist if Java already exists for the intended uses?

IMO, the reason is that the market showed that Java never got used like that. I can only speculate on the reasons, but as far as I can tell it comes down to:

1) The sandbox isn't good enough. See my sibling comment -- the separation between WASM and WASI makes a lot of sense, and I don't think Java had that.

2) The fact that you can't port C code to the JVM easily. In fact WASI addresses exactly that -- the API is more like POSIX than a brand "new" bunch of JVM APIs, which makes it easier to port existing native apps (C, C++, Objective C, Rust, etc.)

In other words, there's still a lot more "value" in native code apps than JVM apps. And it's too hard to port native code applications to the JVM.

For example, Photoshop, Illustrator, Word, Excel, etc. were never ported to the JVM. There are actually better analogs in the browser than on the JVM.

I ran windows for 15 years and Linux for 10-15 years. On neither of those platforms have I ever needed a JVM. I used to play online chess in a Java applet, and that's about it. Most common desktop apps avoid dependencies on the JVM. Probably the only reason I could think of installing one is to use Eclipse or IntelliJ.

The browser is the main reason why anybody had a JVM installed in the first place. Without that hook, the JVM becomes much less important on the client. It's still very important on the server.

Java is important and successful, but it empirically did not succeed at some of its design goals. Of course, WASM and WASI may also fail -- that remains to be seen. But to me they look like a good attempt, based on significantly different technical foundations.

Post reply on HN