sunfish

I work on WASI, and completely agree. A lot of things are not clearly documented right now, and we're working on fixing it.

That cleaner foundation is shared-nothing linking, capability-based security, virtualizable APIs, and more, and a WASI organized around things like streams as first-class types.

The goal is to build a new platform. Initially, that looks like adding layers on top of existing platforms (which, as you say, already have multiple layers). If we succeed, then we get to start taking out some of the layers.

It depends on what you mean by "at the bottom".

If you mean at the bottom of the wasm, the the answer is, those won't be legacy APIs. The direction we're heading is to provide POSIX compatibility as an emulation layer on top of a cleaner foundation, rather than just doing POSIX at the base layer.

If you mean that all Wasm engines today are implemented on top of traditional operating system APIs, then yes, that is how things will often work, but that's ok. What really matters is how the virtual platform works. We don't have to expose things like "the filesystem namespace" directly to wasm, even if it's present in the host. And if we don't expose "the filesystem namespace", then we don't have the associated problems, even if the underlying host has them.

Not yet, at least. But we're working on that :-).

In systems designed for it, communication channels can transmit handles without using a shared namespace or master list. An example of this in the real world is Unix-domain sockets having the ability to send file descriptors across the socket without using a namespace or master list.

It does, but that opens up much more powerful tools to work with.

As an example of one such tool in practice, compare the task of "list all open file descriptors in an arbitrary Unix process" with "list all strings an arbitrary Unix process incorporates some knowledge of". One is a one-liner (`lsof -p <pid>`) and one is really tricky at best, and probably can't be done reliably.

Typing is nice, and when one is working within an existing system where environment variables are the main way for communicating data between parts of a system (which is many popular systems today), this kind of typing looks like it can add some nice benefits.

The blog post linked here is thinking about how the systems themselves could be designed differently, whether that's OS's, frameworks, platforms, languages, clusters, networks, or other things.

There are IPC mechanisms today which aren't just bytes. For example, the ability to send file descriptors over unix-domain sockets. Strings of bytes fundamentally can't do that. And in programs that pass file descriptors, it doesn't require any ghostly assumptions about what namespace the strings need to be resolved in.

To be sure, Unix-domain sockets aren't the answer to everything, but they are an example of a different way to think about communication.

I have a previous-generation Lemur Pro and suspend/resume on lid close/open works great.

Wasm is Turing-complete. What people typically mean by this is that in a browser context, compiling JS to Wasm does not currently make it run faster than just running the JS as JS.

Javascript can be compiled to WebAssembly, and there are people doing it:

https://bytecodealliance.org/articles/making-javascript-run-...

This is true, however if we modify the program to print a 4096-byte long string instead of just the "hello world" string, then it's not sufficient again. And of course, the number 4096 is system-dependent.

So to really do hello world in C right, in addition to fflush, you also need to check the return value from puts. I've never seen any C tutorial do that though.

It's indeed possible! I and others are building a Rust version of this:

https://github.com/sunfishcode/mustang

It supports threads, filesystem, networking, and more!

The library for making Linux system calls is:

https://github.com/bytecodealliance/rustix

If there's community interest, there is a possible path where Mustang matures to the point where it makes sense to talk about how to incrementally migrate the parts that make sense into Rust proper.

First-class values are values which you can pass as arguments, return as return values, and hold in local variables. Values of type `File` or `TcpStream` are first-class in this sense. They show up in function signatures in the same way as any other first-class values, which is what this blog post is interested in.

This is independent of whether the actual I/O is done via mutation/side-effects/execution/etc. or monads/purity/referential-transparency/etc.

It does; the stack pointer starts out aligned, but then the function does a call, and the call instruction adjusts the stack pointer by 8 bytes to push the return address, which would cause it to be misaligned. The push pushes an extra 8 bytes so that the stack pointer is aligned in the callee.

The compiler is using push and pop here just for their side effect of adjusting the stack pointer, to keep the stack pointer 16-byte aligned.

Good catch on that bug! I'll fix that.

Beyond that, that file is just a simple example for showing how to work with the toolchain and the sandbox.

As context, at the time of those issues, the control-flow restrictions were a compromise to help get the "MVP" off the ground, with the understanding that "more expressive control flow" was expected to be added later:

https://github.com/WebAssembly/design/blob/master/FutureFeat...

Unfortunately, we don't actually have data which supports this. The only data that was collected at the time showed that if/else compress better than what wasm has without if/else. There are other ways we could have compressed control flow, but we didn't do the experiments.

WASI has some unique goals around extending the WebAssembly sandboxing concepts into the API space using capability-based security, forming one of the key building blocks for nanoprocesses. Beyond that, WASI will indeed likely reuse existing APIs and API concepts, rather than always inventing new things from scratch.

The article linked here is an advertisement for a startup.

This is discussed in the blog post; see the discussion of "time protection".

Yes. We know that WebAssembly in its present form doesn't yet have all the functionality we'll want to make all this efficient, so we're active in many areas in the WebAssembly standards process helping move it forward.

Wasmtime is being developed to be usable as just such an embedded runtime. We have some demos of this here: https://github.com/bytecodealliance/wasmtime-demos

It's not specifically referring to certification or process, it's more about software architecture. It's referring to how the core WebAssembly instruction set has no I/O instructions, so it can't do anything other than what the APIs given to it allow. And with WASI APIs, the goal is for the APIs to have a similar property, where access to external resources are represented by handles, and WASI-level API functions won't let you do anything without being passed a handle.

WebAssembly is expected to be around a long time, so it's not enough to just measure its speed today, because engines aren't very mature yet. As engines mature, it will likely get faster.

Also, performance is just one factor. Other criteria include security model, standards and governance, Web integration, nondeterminism.

The twist is, you can produce wasm from LLVM, including running the full mid-level optimizer first, which is the part of LLVM where those annotations and aliasing information are most valuable.

Much of what makes Electron Electron are the APIs it provides. The blog post here is a way to describe and work with APIs, not actual new APIs.

We're working on APIs too, in WASI, but there's a lot of work to do to build everything you'd need to build Electron-like apps.

It's a balance. You probably won't see things like Rust's `Vec` exposed as a wasm API by itself, because at that granularity, language-speciric API details are really important, and the actual code you could reuse is relatively small. But at larger scopes, the advantages of mixing languages and introducing sandboxing become more interesting in the balance.

Besides the technology questions, there are also non-technical considerations too. Who do you want governing the package repo you host all your code in?

Note that Wasmtime is the engine starring in the blog post and demos :-).

Of course, cross-language interfaces will always have tradeoffs. But we see Interface Types extending the space where the tradeoffs are worthwhile, especially in combination with wasm's sandboxing.