Hacker News Reader

Comment by ilaksh | Hacker News Reader

Wasn't there some kind of components proposal that would let modules written in different languages running in web assembly interop with each other?

WASI is great but there was an opportunity to standardize on something much more powerful.

Anyway I think the logical extreme of Unix philosophy started with Unix, moved on to Plan 9, and continued to improve from there. It's just that those further advancements are less popular and well known.

An old-fashioned file is not the logical extreme of anything. Not that it isn't useful or interesting.

I stead we don't even have a good way to do any kind of networking.

View on HN

Wasi co-chair and Wasmtime maintainer here: we agree! Wasi Preview 1, which this article is about, was a first attempt at porting some of these Unix ideas to Wasm. We found pretty quickly that unix isn't the right abstraction for Wasm. Not only is it not really portable to platforms like Windows without reinventing a compatibility layer like cygwin, it also doesn't really make sense in a Web embedding, where users end up implementing something like a unix kernel in Javascript.

Wasi Preview 2, which we are aiming to launch by the end of the year, rebases Wasi on the Component Model proposal, which enables composition of Wasm programs, including those which are written in different languages, and which do not trust each other. Wasi is now specified in the Wit IDL, which has a strong type system for representing records, variants, lists, strings, and best of all, external resources, including sugar for constructors, methods, and destructors.

Instead of basing everything on the filesystem abstraction, the core Wasi primitives are the `input-stream`, `output-stream`, and `pollable` resource types, for readable and writable bytestreams, and a pseudo-future: you can `poll-oneoff` on a `list<pollable>` and it will block until one is ready, and return a `list<bool>` indicating the set which are ready. `wasi:filesystem/types.{descriptor}` is the resource for files, but if you need to read, write, or append to a file, you can do so by calling a method on `descriptor` that returns a `input-stream` or `output-stream`.

Preview 2 is also adding networking: wasi-sockets for platforms which support sockets, and wasi-http for those which don't, like the Web.

We are closing in on shipping Wasi Preview 2 but its not quite fully baked yet - changes related to resources are slated to land in the net few weeks. The spec definitions are on github: https://github.com/WebAssembly/wasi-io/blob/main/wit/streams... https://github.com/WebAssembly/wasi-filesystem/blob/main/wit... . Stay tuned for much more approachable documentation, tutorials, and so on, once we are confident it is a stable target ready for users.

The network really is the computer, this time!

Nothing like reinventing COM :)

“COM but you can actually implement it from the docs” is surprisingly compelling, honestly. There is just an absurd number of obscure corners in the original, from DCE RPC all the way to the highest levels (although those are not the only source of COM grief—IDispatch is an abomination; IStream is needlessly annoying; IMarshal is awful to use but at the same time I don’t think actually has a convincing equivalent elsewhere; etc.).

Ah, the pain of getting a DCOM connection working shudder

COM was pretty reliable. Yes, it was needlessly annoying and gave CS folk the screaming ab-dabs, but it worked and was predictable.

I can see COM-in-WASM being really useful. Especially if we can dynamically load components. And not only for browser coding.

Streams sounds more like DrawBridge!

Nobody has a good IPC/RPC-based abstraction set right now. And everybody is kind of struggling with that.

Look at the latest Microsoft thing about embedding Python in Excel. They're going the wrong direction. What everybody wants is to be able to drive Excel from Python aka an API that people could hook into.

Even WASM is kind of ... weak ... because it has to deal with the lowest common denominator--a web page with a single thread of execution and no access to anything.

And, COM wasn't terrible--it's just that the languages attempting to support it were very underpowered at the time. COM with VB6 created a huge ecosystem that probably still isn't really matched today.

COM works well, it’s still heavily used on Windows. The Windows Runtime API’s are just COM! It lets C++\C#\JavaScript\Rust all talk to each other in the same app.

I just think it’s funny since it was so heavily derided by people. It took awhile for me to appreciate its reasons to exist, and I still don’t like some of the vocabulary they used.

And thus AREXX rises from the ashes of the corpse of Amiga.

Please clarify for those of us who aren't Amiga aficionados.

REXX itself was a language made by IBM used for all manner of purposes, AREXX was a slightly simplified take on that for the Amiga. A number of programs on the Amiga would have an AREXX "port" which provided a set of APIs which could be called from AREXX to control aspects of the application. This meant that AREXX was often used to control multiple applications or chain them together (a bit like a batch control language used to achieve an objective by having each of the programs perform part of some greater whole).

Have you looked at capabilities, like E, Mont-E and its descendants?

https://en.wikipedia.org/wiki/Object-capability_model

https://monte.readthedocs.io/en/latest/taste.html#cooperatio...

https://en.wikipedia.org/wiki/E_(programming_language)

Yes, CM resources are unforgable references.

Hmm, a strong type system? Is there any overlap between the Wit IDL and other similar projects like crABI?

Very glad to see this. It's a much better solution that The Unix Philosophy (TM) of sending around unstructured bytes.

> An old-fashioned file is not the logical extreme of anything. ... Instead we don't even have a good way to do any kind of networking.

One can take this further. There was a forgotten system called ChiOs which started with "A bit is a file. An ordered collection of files is a file." and went downhill from there.

"Everything is a file" has its limits.

I rather liked QNX. QNX is a microkernel with microservices. Everything is an inter-process function call. Call, wait for response or timeout. Works both locally and remotely. Very fast locally. There's a POSIX library, but when you call "read", some glue code makes a call to the file system service.

As a base abstraction, remote procedure calls work better than files. Files implemented via RPC are simple. APIs via RPC work are very similar to local function calls. RPC via a file interface is complicated. You have to put a protocol on top of stream/file oriented sockets to get a message interface.

The point that the author seems to be making is that WASI offers a standard API. It's one that crosses a memory protection boundary, like an inter-process function call. This is a reasonable way to do things. For historical reasons, neither Unix nor Windows supports that approach well.

The WASM Component Model

https://github.com/WebAssembly/component-model

Not sure if we continued to improve from plan9, it's more like features were copied from plan9 but due to the fundamental differences in the foundation they aren't really the same and requires boilerplate to be actually usable.

Reply on news.ycombinator.com