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