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

181–190 of 238 posts

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

#181

Post by usrusr »

yellowapple wrote: post #167
McWobbleston wrote: post #155

Earlier quoted context omitted.

Someone correct me if I'm wrong, but don't the JVM and CLR assume they're working with GC'd languages and a number of other things? Making them poor targets for many languages, and AFAIK a WASM runtime is a lot more lightweight than both of them The JVM and CLR seem like they're language platforms first and VMs second

"The JVM and CLR seem like they're language platforms first and VMs second" Ding ding ding ding ding. There are lots of extant application VMs out there, but effectively all of them were implemented specifically to be able to run a specific language (Java → JVM, C# → CLR, Perl 6 → Parrot/NQP/whatever, Erlang → EVM/BEAM, etc.). Other languages have been implemented on top of those VMs, but they have to adopt the seman…

Makes me wonder: is there any language implemented on the JVM that works around the JVM GC the way asm.js works around the js GC? Would it even be possible, could it be performant?

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

#182

Post by Rusky »

chrisseaton wrote: post #160
Rusky wrote: post #124

Earlier quoted context omitted.

The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. WebAssembly does. This is important for a lot of reasons- huge amounts of existing code you can now use without JNI or whatever, a higher ceiling for optimization, more freedom to implement new kinds of languages. The core WebAssembly standard is also much smaller than Java, as a consequence of this design. This makes it easier and/or…

> The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. You can run all those languages on top of the JVM! The JVM also runs many other languages which weren't designed for it, like Ruby and Python.

True, I forgot about Graal. IIUC though that's somewhat different from what WebAssembly has done- Graal doesn't define any sort of stable compiler target for C, or produce JVM bytecode from C, but instead (via Truffle) JITs C source or LLVM IR via partial evaluation, right?

That would suggest (again IIUC) Graal/Truffle as a mechanism for using the JVM as a WebAssembly runtime. The WebAssembly format and its associated environment/binding system are a portable way to encode C binaries, with significant benefits over JVM bytecode- that's probably the comparison I should have made.

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

#183

Post by kllrnohj »

hutzlibu wrote: post #168
kllrnohj wrote: post #108

Earlier quoted context omitted.

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

"Steam, the Windows Store, Play Store, App Store, etc...." And there's also your answer. All those are fragmented, proprietary plattforms. WASI is not.

No, they aren't. They are a variety of distribution mechanisms, which WASI is not and does not contain.

Also, WASI is literally fragmented by design. It does not have a singular target, it instead is a bunch of modules (aka, shared libraries), and what modules you get and how they behave is up to the platform.

Real native has already long since solved distribution, dependency management, and portable abstractions. WASI does not appear to be doing anything interesting, new, or novel here.

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

#184

Post by pdpi »

JeremyBanks wrote: post #111
naikrovek wrote: post #92

Earlier quoted context omitted.

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.

Google's case is less one of "using" Java, and more one of reimplementing it. It's an entirely different legal beast.

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

#185

Post by lyxsus1 »

Others wrote: post #38

This is really interesting. As part of my undergrad research I've built `silverfish`, which is a tool that turns WASM binaries into LLVM bytecode. It's currently pretty chained to how I personally compile my C to WASM, but it'd be pretty cool to get it working with this standard! Here's a link: https://github.com/gwsystems/silverfish -- although the README is pretty sparse, so you'll have to look at the code.

wow, thank you. that's amazing!

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

#186

Post by usrusr »

dahfizz wrote: post #140
eximius wrote: post #105

Earlier quoted context omitted.

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.

I can't shake the niggling idea that this, just like node before it, is more or less a way for JS web devs to not have to leave the ecosystem they're comfortable with and learn a new language. We already have hundreds of ways to write native UI applications, but web devs can't bother to use them.

When you put WASM into something that isn't a browser then it still won't be a browser afterwards. WASM is not DOM+CSS.

On top of that, JS devs would be the ones who get the short end of the stick, because js is the one language that does not compile to WASM because where WASM comes from, you already have a JS environment, no need to build a second one inside WASM.

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

#187

Post by chrisseaton »

Rusky wrote: post #182
chrisseaton wrote: post #160

Earlier quoted context omitted.

> The JVM doesn't run languages that weren't designed for it, like C or C++ or Rust. You can run all those languages on top of the JVM! The JVM also runs many other languages which weren't designed for it, like Ruby and Python.

True, I forgot about Graal. IIUC though that's somewhat different from what WebAssembly has done- Graal doesn't define any sort of stable compiler target for C, or produce JVM bytecode from C, but instead (via Truffle) JITs C source or LLVM IR via partial evaluation, right? That would suggest (again IIUC) Graal/Truffle as a mechanism for using the JVM as a WebAssembly runtime. The WebAssembly format and its associate…

No that's right, the stable compiler target is someone else's job.

But I wasn't comparing to WebAssembly, so you'll need to argue that point with someone else.

You could build a WebAssembly interpreter on Truffle, yes. I'm not sure anyone's tried it yet so that project is available.

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

#188

Post by int_19h »

millstone wrote: post #163
_bxg1 wrote: post #161

I've heard people predict that the future of the web is to replace userland, to make every program cross-platform and sandboxed close to the metal, and for JavaScript to fade into a family of "web"-targeted languages. Looks like it's happening.

In this scenario, what's the point of having more than one OS?

Same as with POSIX - different implementations of the same standardized interface that target different hardware, and have different quality of implementation (possibly optimized for different use cases).

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

#189

Post by wahern »

jcranmer wrote: post #47
writepub wrote: post #37

I would love for WASI/WasmTime to emphasize on: 1. Backwards compatibility with existing libc. (Maybe pick musl) 2. Platform agnostic wasm generation: the same wasm file should run in the browser (with emscripten polyfills) and across ALL OS-es, mobile included. List: iOS, Android, Mac, Linux, Windows, FreeBSD #1 shall enable decades of legacy programs to work with minimal porting, while #2 shall enable true cross pl…

> 1. Backwards compatibility with existing libc. (Maybe pick musl) Honestly, that ought to be a non-goal. We already know that POSIX often enforces models that we don't want--filesystem permissions and the fork model are two good examples of things that are broken. So why start with "implement POSIX"?

POSIX doesn't mandate fork, that's why it invented posix_spawn.

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

#190

Post by int_19h »

pjmlp wrote: post #42
rapsey wrote: post #31

Earlier quoted context omitted.

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

AS/400 TIMI comes to mind, and CLR as well.

CLR sandbox should not be considered a meaningful security boundary at this point. CAS and partial trust are both officially obsolete.

The problem is always complexity. It can be difficult to reason about safety with so many features on bytecode level. There have been exploits using dynamically-generated methods, exception filters, and vararg handling - note the near-lack of any common patterns here other than they're all obscure features of the platform, the security impact of which wasn't fully analyzed.

For example, a long time ago, I reported the vararg exploit, which boiled down to the fact that you can have ArgIterator over an argument list containing another ArgIterator, allowing the latter to be mutated via the former. Thus, you can stash away an ArgIterator to the arguments of a function call that has already returned. This is basically the same as having a managed reference to a managed reference, and it's exactly why CLR prohibits this - but they forgot that ArgIterator is also a kind of a managed reference.

Post reply on HN