Libc++ 9.0.0 adds explicit support for WASI | Hacker News Reader

Libc++ 9.0.0 adds explicit support for WASI

releases.llvm.org

Is WASI (WebAssembly System Interface) a way to run WebAssembly outside of the browser on (theoretically) any device or is this a way to do systems programming in WebAssembly?

Yes, it's like the libc of WASM. https://wasmer.io is a runtime with WASI support

Its an evolving standard set of system interfaces. Right now it supports sandboxed access to the filesystem via a POSIX-like api, as well as other basic interfaces like argv, environment variables, random numbers, and timers.

https://wasi.dev

Say you have `shared_library.so` which exposes methods/APS `foo()` and `bar()`

How would you load them/link against them + call them in Webassembly land?

By using dynamic loading capabilities of WebAssembly runtimes.

Watch Lin Clark's closing keynote at RustConf 2019.

https://www.youtube.com/watch?v=VlIydW5Fojw

Doesn't it kind of stink that there are so many WebAssembly runtimes? Fragmentation, different ways of doing things, etc.

No? Would you prefer there was just one? That might make some things better, but it would make a great many things much worse, and make it much harder to fix them.

Ideally we'll get to a few very good ones that are alle considered acceptable for most things that will steal good ideas from each other and experiment to find interesting ways forward.

Nobody except their controlling entities really benefited in the long run from having IE as the vastly dominant browser, and I doubt we'll benefit from Chrome's emerging dominance to the same degree. IMHO, the compiler market was greatly benefited by the emergence of Clang as well. Competition is good.

No, this is what freedom and innovation looks like.

Javascript has become mostly a lost cause as far as open source development goes, as it's basically owned and controlled by NPM Inc and corporate interests now, but WebAssembly at least still has the possibility of remaining open.

At the very least, we should go through a period of experimentation by the community to settle on the best possible solutions (or sets of solution) and let things mature a bit, first. Now is not the time to bless a single runtime, package manager, etc.

WebAssembly is developed by the same corporations that own JavaScript.

They don't own the runtime and package manager, though.

Although Wasmer does come with a package manager (WAPM) that uses a proprietary registry like NPM, at least the developers have said they're committed to decentralized hosting[0]. Maybe someone can come up with a completely distributed package management alternative, which I would prefer, but at least Webassembly isn't yet at the degree of centralization that Javascript is.

[0]https://news.ycombinator.com/item?id=19732794

Which are utterly meaningless with the specification developed by said corporations.

And really, the only thing going for WebAssembly is being the PNaCL that those corporations were willing to agree on.

It's not the best possible scenario but "utterly meaningless" is hyperbole.

Certainly it's better not to have every aspect of a language be centralized. It's already near impossible to distribute Javascript, or even software in many languages, without going through NPM. WebAssembly, thankfully, isn't there yet.

It surely is meaningless, because whatever your favourite WebAssembly implementation is capable of, ultimately it only matters if it is spec compliant.

A spec, which is under control of those organisations.

What organisations should control a standard if not those that develop implementations?

The point is that WebAssembly isn't something independent of JavaScript masters control as the OP is portraying.

In my experience you will still have to compile your .so as wasm with exported methods.

I'm not very familiar with WASI. For this to be useful for in-browser wasm apps, would browser wasm runtimes have to implement WASI too? If so, are any browsers looking at doing this?

I do know that there are WASI runtimes for non-browser wasm applications.

I don't think this exists yet, but it is definitely possible to write a WASI runtime in pure JavaScript. A precursor to WASI, jfbastien's musl fork, had one:

https://github.com/jfbastien/musl/blob/wasm-prototype-1/arch...

Exceptions still don't work! That ends up making lots of C++ code not compilable.

That's not a limitation of WASI - WASI is just the system APIs.

Exceptions don't work natively in wasm yet, that's true. But they do work in wasm+JS (using JS exceptions for unwinding, in Emscripten).

Yeah, Emscripten does support exceptions, but I don't think Emscripten creates WASI yet? It would be useful to separate out the exception handling from Emscripten to a runtime library so that other projects could use it, without relying on the entire Emscripten toolchain.

I suspect we'll get exception handling at some point, but for now so much stuff just does not work without it. The whole idea of WASI is that it is not JavaScript-specific, so needing some JavaScript code just to get this basic feature is kind of surprising.

Emscripten does use some WASI APIs already, both normally and especially in standalone mode [1].

But yeah, for now WASI and wasm don't provide enough to do things like C++ exceptions, longjmp, etc., so Emscripten supports them using non-WASI APIs.

Native exception handling for wasm is being worked on. If we don't want to wait for that, we could do exceptions using Asyncify [2]. But since we have the JS+wasm option for now, and native support coming, that's maybe not worth it.

[1] https://github.com/emscripten-core/emscripten/wiki/WebAssemb...

[2] https://www.youtube.com/watch?v=qQOP6jqZqf8

WebAssembly people continue to reinvent java, it seems

I don't think Java bytecode was intended to be a portable representation targetable by any language. It was to be the representation for the Java language. Java applets have inferior sandboxing. [1]

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

Follow my sibling comment for examples all the way back to 1958.

JVM yes was initially designed for Java alone, but its research successor, GraalVM, does understand LLVM bitcode thanks to Sulong.

As for "superior" WebAssembly sandboxing, it doesn't protect against internal corruption, due to lack of bounds checking on memory access. Which allows for injected scripts to try to coerce a loaded module to change its behavior. No need to escape the sandbox, sometimes changing the outputs is all that an attack requires.

It remains to be seen how many WebAssembly CVEs will appear when it starts to be more widely targeted by black hats.

And if those WASI modules happen to be written in languages like C and C++, I expect a couple of them to show up.

If WebAssembly is running in the browser, it’s not calling into C/C++ modules. If WebAssembly isn’t running in the browser, it doesn’t need to be sandboxed. Thus I don’t think we need to be concerned over WASI sand boxing in the same way as applets.

If JavaScript is calling into WebAssembly modules compiled from C and C++, naturally do we have to care about security.

The existing model does not prevent exploits taking advantage of internal memory corruption inside the sandbox.

Not only Java

UNCOL - https://en.wikipedia.org/wiki/UNCOL

IBM i ILE - https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/...

IBM z/OS Language Environment - https://www.ibm.com/support/knowledgecenter/zosbasics/com.ib...

Xerox Mesa - http://www.softwarepreservation.org/projects/lang/mesa

Xerox Interlisp-D - http://www.softwarepreservation.org/projects/LISP/interlisp_...

UCSD P-Code - https://en.wikipedia.org/wiki/P-code_machine

Modula-2 M-Code - https://www.cfbsoftware.com/modula2/

CLR - https://www.ecma-international.org/publications/standards/Ec...

PNaCL naturally - https://developer.chrome.com/native-client/reference/pnacl-b...

And many many others that I didn't bother to refer to, just WebAssembly is cooler somehow.

Well, WebAssembly has a really nice formal semantics with a machine-checked proof of soundness. It is pretty cool.

And with all of that, it's utterly disqualifying for a systems language to have garbage collection.

The fact it's been done means it's impossible to do. Well-known fact.

Xerox PARC, TI, MIT, ETHZ, Microsoft, Apple and Google beg to differ.

In fact, Swift, Go, Java and .NET Native seem to be doing relatively well across their systems level projects, regardless on what naysayers think.

Swift as C and Objective-C replacement on Apple platforms.

Go as the implementation of gVisor used on ChromeOS Crostini security layer and Compute Cloud, Android GPGPU debugger, Fuchsia's TCP/IP stack.

Java, alongside C++ for writing Project Trebel and Android Things drivers. Letting aside all those real time Java projects that run it bare metal, using the likes of PTC, Aicas and Gemalto compilers.

.NET Native across Windows IoT Core and Azure Edge modules.

But lets keep hating GC systems based languages instead.

Either I suck at conveying sarcasm or you suck at picking up on it.

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."

https://news.ycombinator.com/newsguidelines.html

Except java is proprietary, and requires a separate JVM, with all its GUI bloat and backward compatibility, while WASM was instantly implemented by all browsers and only does a very limited set of things, which is running an almost-binary in a browser.

Any language can be compiled into WASM, but java being garbage collected, it's far from being the case.

WASM is agnostic and flexible and allows a broad range of things.

Java was never designed with the web in mind, and money ruined it, because it tried to do everything, but did everything poorly. WASM can actually make fast webapps a reality, maybe even on android.

And even if it reinvents java, so what? At least it replaces it and fixes its many problems, they are many things that cannot be done in java. Its VM had no chance to be made standard in browsers...

So in short, if you reinvents something, but you make it an open standard, it's clearly an improvement.

Java is under GPL with Classpath exception.

Since more than a decade after its initial release and well into the JavaScript revolution that made it obsolete in the browser.

Flash was what made Java obsolete on the browser, and both of them will take JavaScript crown thanks to WebAssembly + WebGL.

I still dont understand the point of this. Why are people trying to turn JavaScript into a systems programming language? It isnt, has never been, and never will be that.

If you wish to use a systems programming language, use a systems programming language. Plenty of old ones (Java, C, C++) and plenty of new ones (Go, D, Nim, Rust, Zig) are available. Its like people took a square piece of rock and said:

A: hey, lets chip off some corners so that this can roll!

B: but now its an octagon...

A: well if you put it on a hill it can tumble down!

All the while several styles of modern wheels sit behind them.

Webassembly isn't Javascript?

I mean, people probably are trying to do systems programming in Javascript, and I agree that's ridiculous, but this isn't an example of it.

Webassembly is just a spec for a language agnostic bytecode. Despite it's name, it isn't even meant to run only in the browser.

> Webassembly is just a spec for a language agnostic bytecode. Despite it's name, it isn't even meant to run only in the browser.

It's the same kind of namewashing as javascript's on name. Once more and we can call it a tradition!

Uh, I think you have the metaphor the wrong way around. The goal of wasm / wasi isn’t to allow javascript to be a systems language. It’s to allow systems languages to be used in javascript, or allow them to interoperate with one another or run on different operating systems, or run on different hardware platforms.

In javascript we’ve been stuck using octagon wheels but there’s all these new modern wheels sitting around that we haven’t been able to use because browsers could only run javascript. But now we have a way to fit the modern wheels on our javascript car.

But I gave you octagon wheels because I don't want you using real wheels.

You don’t want web developers to have access to the tools we need to make websites cpu and and memory efficient?

I for one am sick of web apps being so slow and bloated. The day react’s code runs in wasm with native wsdl calls is the day websites the world over will suddenly get a lot faster. What is the problem with that?

And also the day every browser will turn into IE 5.x

WASM is not Javascript.

WASM is solving the problem Java tried to solve many years ago (and for the most part failed): write once, run anywhere.

Because js is an interpreted language with all the problem is carries, it was designed in 10 days and many developers can't stand it. Optimized js engines are very complex and cannot be fast on smartphones. Did you know those engines optimize code while it's running based on execution paths? It's a nightmare for determinism.

Enabling an agnostic compile target is the greatest thing that could ever happen to the web.

Reply on news.ycombinator.com