That is why I love Plan 9. 9P serves you a tree of named objects that can be byte addressed. Those objects are on the other end of an RPC server that can run anywhere, on any machine, thanks to 9p being architecture agnostic. Those named objects could be memory, hardware devices, actual on-disk files, etc. Very flexible and simple architecture.
The real interesting magic behind Plan 9 is 9P and its VFS design so that leaves Inferno with one thing going for it: Dis, its user space VM. However, Dis does not protect memory as it was developed for mmu-less embedded use. It implicitly trusts the programmer not to clobber other programs memory. It is also hopelessly stuck in 32bit land.
These days Inferno is not actively maintained by anyone. There are a few forks in various states and a few attempts to make inferno 64 bit but so far no one has succeeded. You can check: https://github.com/henesy/awesome-inferno
Alef was abandoned because they needed to build a compiler for each arch and they already had a full C compiler suite. So they took the ideas from Alef and made the thread(2) C library. If you're curious about the history of Alef and how it influenced thread(2), Limbo and Go: https://seh.dev/go-legacy/
These days Plan 9 is still alive and well in the form of 9front, an actively developed fork. I know a lot of the devs and some of them daily drive their work via 9front running on actual hardware. I also daily drive 9front via drawterm to a physical CPU sever that also serves DNS and DHCP so my network is managed via ndb. Super simple to setup vs other clunky operating systems.
And lastly, I would like to see a better Inferno but it would be a lot of work. 64 bit support and memory protection would be key along with other languages. It would make a better drawterm and a good platform for web applications.
Unix, Plan 9 and the Lurking Smalltalk
https://www.humprog.org/~stephen/research/papers/kell19unix-...
Late binding is a bit out of fashion these days but it really brings a lot of cool benefits for composition.
"UNIX Needs A True Integrated Environment: CASE Closed"
http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-4...
For the TL;DR; crowd
"We 've painted a dim picture of what it takes to bring IPEs to UNIX. The problems of locating. user interfaces. system seamlessness. and incrementality are hard to solve for current UNIXes--but not impossible. One of the reasons so little attention has been paid to the needs of IPEs in UNIX is that UNIX had not had good examples of IPEs for inspiration. This is changing: for instance. one of this article's authors has helped to develop the Small talk IPE for UNIX (see the adjacent story). and two others of us are working to make the Cedar IPE available on UNIX.
What's more. new UNIX facilities. such as shared memory and lightweight processes (threads). go a long way toward enabling seamless integration. Of course. these features don't themselves deliver integration: that takes UNIX programmers shaping UNIX as they always have--in the context of a friendly and cooperative community. As more UNIX programmers come to know IPEs and their power. UNIX itself will inevitably evolve toward being a full IPE. And then UNIX programmers can have what Lisp and Small talk and Cedar programmers have had for many years: a truly comfortable place to program."
