Live data from Hacker News

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

hacks.mozilla.org

101–110 of 238 posts

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

#101

Earlier quoted context omitted.

Yes!

How will you deal with valid paths such as: /tmp/[DE][AD][BE][EF].txt # ext2 / linux # OR C:\stuff\[DEED][FFFE].txt # ntfs / windows # where [hex] indicates a single filesystem charater with that value

One fun thing about the capability model is that at the system call level, there are no absolute paths. All filesystem path references are relative to base directory handles. So even if an application thinks it wants something in C:\stuff, it's the job of the libraries linked into the application to map that to something that can actually be named. So there's room for the ecosystem to innovate, above the WASI syscall layer, on what "C:\" should mean in an application intending to be portable.

Concerning character encodings, and potentially case sensitivity, the current high-level idea is that paths at the WASI syscall layer will be UTF-8, and WASI implementations will perform translation under the covers as needed. Of course, that doesn't fix everything, but it's a starting point.

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

#102
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?

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

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

#103
post #22

Excuse me if I come across as naive, I'm kind of a noob on these architectural topics, but how is this different/better than what the JVM is/accomplishes? When WASM first popped up I thought about the similarities with Java Web Applets and Flash.

1. It's an open standard that the major browsers have agreed to, so it's not a plugin that you have to install. A WASM app will work seamlessly in your browser without any additional software. 2. WASM is designed from the ground up as a compile target, not a language. We already see many languages with support for building to WASM. C, C++, Rust, and eventually when WASM supports garbage collection we'll probably see…

(1) could be resolved by shipping Java, let's say hypothetically.

(2) the JVM was designed from the ground up as a compile target also, for Java, but is also used by Kotlin, Clojure, Ruby (JRuby), Python (Jython) and Scala, among others. Even JavaScript (Rhino, Nashorn and Graal).

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

#104
post #31

Earlier quoted context omitted.

Yeap, so innovative it existed already for decades (virtual machine executing some fixed bytecode).

Properly sandboxed VM that you can compile practically any language into?

JVM and CLR.

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

#105
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?

you can use html/css/js with it, I guess :/

Or, more accurately, its easy to make UIs for it?

I'm personally bearish on the whole idea from a community / technical standpoint (in that I'd like us to return to more native stuff than follow JS into the browser), but I can't argue that WASM and co won't enable some really cool uses.

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

#106
post #97
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?

Different use cases. You don't necessarily want a 10 ton standard library for every use case, like on embedded devices or plugins for a software package. C/C++/Rust being 1st class citizens is also very useful.

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?

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

#107
post #29

This is nice and I'm excited about it, however there is a concern that people are going to start building code that targets WASI and then shim it to run in the browser. This happened to JavaScript when Node.js was released; people began using APIs intended for servers and then shimmed them to also run in the browser resulting in code bloat. I'm worried that the same is going to happen here; the video actually encoura…

I think the browser shouldn't be a platform at all, frankly, and WASI is one possible way we can finally stop trying to shoehorn it into being one. If everything runs a WASI runtime, which is designed to run applications from the ground up, there really isn't any need for the browser to run applications anymore, is there?

So every web site you visit now balloons to 150MB of code that just badly reinvents what Chrome & Firefox did? And also just runs with, what, all permissions & capabilities? Or no permissions? GPU, video, audio, etc... are all just not allowed then?

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

#108

Earlier quoted context omitted.

That's like saying "now that we have Minix there isn't any need for Windows anymore". WASI is awesome, but the Web is here to stay.

For sure, but it would be nice if there were alternative ways to run "no-need-to-install" apps without bringing all the weight of a browser with it. There's a large class of apps that don't need to link out to other URLs, don't need CSS engines (if they just need opengl/vulkan for example), and might not need as strict of security as a web page.

> There's a large class of apps that don't need to link out to other URLs, don't need CSS engines (if they just need opengl/vulkan for example), and might not need as strict of security as a web page.

Yes, there are, and those uses are already solved with Steam, the Windows Store, Play Store, App Store, etc....

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

#109
post #97

Earlier quoted context omitted.

Different use cases. You don't necessarily want a 10 ton standard library for every use case, like on embedded devices or plugins for a software package. C/C++/Rust being 1st class citizens is also very useful.

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?

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

#110
post #102
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?

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 in native environments. I'm a younger developer and only partly remember the days of Java on the web, but is there a reason for why JVM is not suitable in web environments? I.e. why WebAssembly -> Native, not JVM -> Web?

Post reply on HN