[HN Gopher] Reaching the Unix philosophy's logical extreme with ...
       ___________________________________________________________________
        
       Reaching the Unix philosophy's logical extreme with WebAssembly
        
       Author : xena
       Score  : 91 points
       Date   : 2023-08-27 16:58 UTC (1 days ago)
        
 (HTM) web link (xeiaso.net)
 (TXT) w3m dump (xeiaso.net)
        
       | hoten wrote:
       | Wonderful talk, now I finally understand what WASI is.
        
       | beeburrt wrote:
       | This person is amazing. I wish I was half as smart and just as
       | funny
        
       | galaxyLogic wrote:
       | Everything is not a file. There are files and file-contents. The
       | content of a file is not a file.
       | 
       | The magic trick happens with #SheBang because that tells you who
       | should interpret and execute the file-contents. That is "magic"
       | because in a sense you must read (part of the content) to know
       | how the contents which is just 0s and 1s should be interpreted.
        
         | teruakohatu wrote:
         | > Everything is not a file.
         | 
         | A file is a collection of data, which usually has an associated
         | identifier (filename and/or path). A USB mouse drive is not a
         | file, but it can be represented as such.
        
         | wahern wrote:
         | There are two dimensions to "everything is a file". The first
         | is the concept of a hierarchical filesystem namespace. The
         | second is the notion that read and write can be used as a
         | universal interface to any resource from the perspective of the
         | runtime environment (e.g. kernel). People focus myopically on
         | the first aspect, but it's really the second that is the most
         | important and most enduring.
         | 
         | The word "file" is ambiguous, and was used ambiguously in Unix
         | documentation and papers. It of course meant an object with a
         | name in the filesystem. But it also can refer to an object
         | (whether or not existing or even referenced by the filesystem)
         | which is accessed using read/write, independent of how you
         | acquired the reference (i.e. file descriptor) to that object.
         | If you look at the whole of the Unix system, read/write over
         | file descriptors is the backbone of the environment; from
         | process control to shell commands, much of the time a program
         | has no idea _how_ a resource reference was required, just that
         | it can be accessed using read /write.
        
         | [deleted]
        
       | ilaksh wrote:
       | 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.
        
         | phickey wrote:
         | 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.
        
           | actionfromafar wrote:
           | The network really is the computer, this time!
        
           | fassssst wrote:
           | Nothing like reinventing COM :)
        
             | mananaysiempre wrote:
             | "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 it's 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.).
        
             | lukeh wrote:
             | Streams sounds more like DrawBridge!
        
           | ori_b wrote:
           | 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)
        
             | phickey wrote:
             | Yes, CM resources are unforgable references.
        
         | [deleted]
        
         | Animats wrote:
         | > 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.
        
         | magila wrote:
         | The WASM Component Model
         | 
         | https://github.com/WebAssembly/component-model
        
       | some_furry wrote:
       | > It's magic, just without the spell slots.
       | 
       | I laughed out loud during a work meeting when I read this. Bravo,
       | Xe!
        
         | lifeisstillgood wrote:
         | You were reading HN during a work call ! Call HR !
        
           | [deleted]
        
       | jl6 wrote:
       | The UNIX philosophy's logical extreme is the NAND gate. Does one
       | thing, does it well, and can be composed into arbitrary
       | applications.
        
         | Someone wrote:
         | One thing? It does a logical and and then negates the result.
         | The shell doesn't really let users compose commands this way,
         | but                 alias NAND="AND | NEG"
         | 
         | Also, a NAND command would need to have 2 _stdin_ 's.
        
         | Drakim wrote:
         | Only if the NAND gate is expressed as a file
        
           | Waterluvian wrote:
           | Okay... please... someone implement 'nand' and write a script
           | that does something simple using only it.
        
             | jewel wrote:
             | Sure! Here's an implementation of nand and a 2-bit adder
             | that uses it: https://github.com/jewel/nand
        
               | Waterluvian wrote:
               | Hah this is awesome!
               | 
               | I'm going to poke around and see how much it would take
               | to stretch this into a basic Turing machine emulator.
        
             | [deleted]
        
         | [deleted]
        
       | bykhun wrote:
       | I wonder if we can reliably expect React-in-Rust framework that
       | compiles to wasm instead of js? Or maybe just a React library
       | written in Rust, but you can still write the source code in
       | javascript?
       | 
       | Or maybe at least Typescript-to-WASM compiler to skip JS output?
        
         | capableweb wrote:
         | I mean probably, yeah, but why? You'd still need JS to involve
         | the DOM with anything, and that's the performance expensive
         | stuff, so might as well just do the whole thing in JS.
        
       ___________________________________________________________________
       (page generated 2023-08-28 23:00 UTC)