Live data from Hacker News

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

hacks.mozilla.org

111–120 of 238 posts

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

#111

Earlier quoted context omitted.

Using Oracle's Java Programming Language is an immeasurable legal liability.

There are open source and non-Oracle Java virtual machines you can buy support from if Oracle isn't your cup of tea. It's not really a legal liability either. Lawyers for companies who use Java go over those agreements with a fine tooth comb and approve them before they're signed. There are no surprises (if your attorneys aren't frauds.)

Google's was not using Oracle's virtual machine, and their attorneys were not frauds, but they've been tied up in litigation for most of a decade and are facing potentially ten billion dollars in penalties.

https://en.wikipedia.org/wiki/Oracle_America,_Inc._v._Google....

Java is not a responsible or ethical choice for anybody to use for any purpose.

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

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

I'll take a stab at it. While both WASM and the JVM aim to be portable virtual machines, WASM prioritizes sandboxing / security and a smaller runtime. A host should be able to easily set up WASM with restricted access and expect that the WASM program is secure. As far as I know, the JVM doesn't have an equivalent feature, or if it does, it's a lot more complicated.

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

#115
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…

I've now found a blog post[0], which seems to outline two main reasons for WASM over JVM on the web:

1. WASM is an open standard

2. WASM spec is smaller, so it's easier to integrate into the Javascript VM, which itself brings many benefits

Since WASM wins on the web, I guess it makes sense for developers to want to develop one version of their code for both the web as well as native environments. Thus, WASM -> Native seems to totally make sense.

[0] https://words.steveklabnik.com/is-webassembly-the-return-of-...

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

#116
post #78

Can't help being reminded of that talk by Gary Bernhardt: “The Birth & Death of JavaScript”[0] — exploring a hypothetical future where JS takes over everything without (most) anyone using it of their own volition. 0: https://www.destroyallsoftware.com/talks/the-birth-and-death...

Except entirely irrelevant as WASM is not Javascript.

Can you show me an example of a WebAssembly app that runs in the browser with JavaScript enabled?

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

#117

Earlier quoted context omitted.

For embedded devices you'd always be better just compiling C/C++/Rust directly to the native code. You don't have any portability possibility there in the first place anyway, so why ship inferior code gen with arbitrary restrictions?

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?

is it really a use case for WASM?

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

#118
post #91

Wait a second... I thought Java was supposed to do this with the JVM... I thought .Net was supposed to do this with the CLR... What's different now?

The JVM and CLR suck balls.

They put in huge amounts of effort into things that don't need solving, and the things that need to be solved they do in the most roundabout way possible.

What we _really_ need is a sandboxed VM for running C code securely and efficiently.

The JVM is pretty much the opposite of that; it's not sandboxed, not secure and certainly not efficient as a target for C code.

We're hoping WASM starts over from scratch and does things right this time around.

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

#119
post #46

Earlier quoted context omitted.

Yeah, sure, you go ahead and reinvent 30 years of cross-platform application APIs. I'll keep using the web until your new ones match maturity.

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).
Post reply on HN