Hacker News Reader

Comment by DiabloD3 | Hacker News Reader

As of someone who discovered Plan 9 far too late to do anything about it: everything is a poor man's Plan 9 something. Everything. All of it.

Plan 9 lived in the goddamned future.

View on HN

Looking at the Unix to Plan 9 translation [1] gives me a different opinion. To name one egregious example, omitting find(1) in favor of piping du(1) (what is supposed to be a disk usage analyzer) to grep(1) is not an improvement; it's just user-unfriendliness in service of minimalist aesthetics. (Contrary to popular belief, find(1) is not a particularly "bloated" program; Rust's "fd" implementation is under 7,000 lines of code [2], about a third of the size of Lua.)

[1]: https://9p.io/wiki/plan9/Unix_to_Plan_9_command_translation/...

[2]: https://github.com/sharkdp/fd

The problem with find is that it tries to put an entire programing language into its arguments.

I agree with you to some extent, but the solution is fd: change the tool's interface to make simple things easy. Deleting the tool entirely does nobody any favors. As bad as find(1) is for simple stuff, piping du(1) to grep(1) is worse.

That's half of the solution. The other half, I'm convinced, will be a tool that makes complex things possible. After all, if I really need some complex filtering, find's primitive logical operators probably wouldn't even be sufficient. To that end, I love how Nushell's leading example on their home page is

    ls | where size > 10mb | sort-by modified

It seems so elegant! Down with strings! …But it's not my life yet, since last time I wanted to try Nushell they didn't have scripting yet, and I have yet to circle back around to it. There's also Elvish and PowerShell and Oil Shell but they all have their own issues.

zsh solves this with globbing qualifiers:

  ls -t *(Lm+10)

"L" for the "file size" qualifier (why "L"? For "less than size", I think – probably because "s" is already used for setuid), "m" for megabytes, "+" for "larger than". You can also add "om" or "Om" to sort by mtime, but ls will reorder it so you need the -t flag (or the -U flag to not sort things).

The syntax is not easy, even byzantine, but it's a lot less to type and pretty convenient in interactive shells.

> Nushell they didn't have scripting yet

If you mean you couldn't run batch scripts from a file, they can do that now. There's an example repo with some community scripts. My favourite is how they handle CLI parsing: https://github.com/nushell/nu_scripts/blob/main/sourced/nu_1...

Is that a problem? A simple tool is good if it can solve complex problems, but a simple tool that can't is just an underdeveloped tool. Sometimes you need a complex tool to solve a complex problem.

I think a good mini language bridges the gap between interactive commands and programming. Sometimes you need to spend an hour writing a program to do something complicated. But because of various "extraneous features" built into UNIX commands, you rarely need to spend an hour manually poking at the filesystem. The mini language gets you almost as productive as a full-fledged programming language, without feeling like you're programming. (How do you know you're programming? If you "git init" and start committing stuff, you're probably programming. If your carefully-crafted thing scrolls into .history obscurity, then you're interacting.)

Find is not simple - it's easy, but internally complex. It's fine to solve a complex problem with a complex tool, but it's troublesome when people mostly use it to solve simple problems. And the trouble is that this kind of approach spreads to every single component in the system, which means that we're using insane amount of code and cpu load to solve really simple problems on daily basis.

Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.

…we're using insane amount of code and cpu load to solve really simple problems on daily basis.

Piping programs together is almost always going to use significantly more resources than one program doing it all. More code doesn’t necessarily imply more resource usage.

Plan 9 is not an answer to every problem, but it's just impressive how much it can do with so little code.

I don’t want to be all around negative about plan 9, but I don’t see it as really solving any interesting problems. Indeed it is far easier to write slim, elegant systems when forgoing feature parity and/or competitive performance.

> More code doesn’t necessarily imply more resource usage.

That's true! Yet, somehow we found ourselves in a situation where most people use computers, to chat, read news etc, all of which would be possible with much less resources. All done with the use of platforms that we literally can't rewrite, as they're too complex. It's certainly not find's fault, but the complexity creep starts somewhere.

Plan 9, as a research OS, is not a useful platform to base your next business on, but it does serve as a baseline we can relate our "real" platforms to.

Little conveniences cost a lot.

Just having a framebuffer with page flipping for seamlessly redrawing the screen costs 64MB of memory at 4K resolution. People did real work and gaming on computers with a small fraction of that.

Early on in the history of computing the framebuffer was discussed as a theoretical construct, like "what could we do with this concept if we had the memory to implement it".

After staring down find(1) on an AIX system I regret not going down the du | grep path. At least that way I wouldn't be stuck trying to mash GNU's parameters into completely incompatible version of find.

If your system supports `man 1p` (loading the posix manual for each supported utility), it is a good idea to reference that instead of the default manpage; it is more likely for your utility to support posix options than GNU extensions in legacy and non-linux systems.

>I think a good mini language bridges the gap between interactive commands and programming.

find(1) is a bad mini language. Its arguments are in a legacy format and its solution for composability is a hack, and an unstable one.

And shell users already have a language they know & should be able to use to compose computing: the shell.

Different programs introducing their own specific programmatic layers defeats the holistic small pieces, loosely coupled premise.

Hear hear. When I use find I only use it for the recursive dir listing with no arguments. I always pipe it into grep because I know grep better.

Hard to grep a list of path names for size or last modification date?

When I saw the start of this thread, I thought abusing "du" for "find" sounded insane - but after mulling it over - I guess du is just a recursive stat(1).

And I can see the logic; have a tool that builds a tree of metadata, filter with a tool that... filters.

However - as far as i can tell, du/grep on plan9 can't fill in for find(1) - but the idea (above) would probably fit with PowerShell or other "typed/rich streams" kind of shell...

https://man.cat-v.org/plan_9/1/grep

https://man.cat-v.org/plan_9/1/du

And it makes easy things hard.

All the time arguments and size parameters and rules about depth and boolean syntax and the print0 for pipeline integration ... it makes me long for DOS interfaces from the 80s. There has to be a way to do it with less intellectual lifting every time.

Maybe just a simple set of bash reads will help - that's how I do ssh port forwarding - I was tired of getting confused.

Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video". (This would be at the frontend in this (currently) fictional helper script)

> and the print0 for pipeline integration

The existence of things like `-print0` is the downside of Unix's "all files/pipes are byte streams" design decision.

The IBM mainframe implementation of the pipeline idea – CMS Pipelines [0] – makes pipes record-based instead. Since the pipes are not streams of bytes, rather records with out-of-band boundaries, there is no need to reserve a special character (whether LF or NUL) to serve as a record separator.

> Integration with /etc/mime would be nice as well so I can just search for, say, "image" or "video"

It is a pity that Unix never had a "file type" field in the filesystem, unlike classic MacOS, Acorn RISC OS, among others. I suppose both those systems had the limitation that the file type was just a number, subsequent experience has demonstrated it needs to be a much longer string (such as a MIME type or Apple UTI). The problem with file extensions is the same extension ends up being used by completely unrelated applications for completely unrelated file formats – e.g. nowadays .doc is normally assumed to be legacy binary Microsoft Word, but many older archives it is a plain text file instead, or sometimes even some other word processing format.

[0] https://en.wikipedia.org/wiki/CMS_Pipelines

Sure, which lends weight to the idea that the shell should be a more extensive programming language. Then you can pass an arbitrary Predicate<File> to the finder (which would likely just be a convenience function of about 5-20 lines), and receive a list of file objects for you to do what you want with

That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has become so ubiquitous and influential that we've forgotten that programs could pass more than ill-specified strings around, and that resources could implement richer interfaces rather than trying to force the file IO interface on every single one, regardless of how little sense that makes

Worse is Better may have been a useful expedience in the 20th century, but we're long overdue repaying that technical dept, to get back some of the rich OS/environment features that other camps had got working almost half a century ago. The first step would be to stop putting "Unix philosophy" on a throne

"That's the direction Powershell took, and to some extent was what other OSes were doing at the time of Unix. But Unix has become so ubiquitous and influential that we've forgotten that programs could pass more than ill-specified strings around ... The first step would be to stop putting "Unix philosophy" on a throne "

Well yes, but I think it will be hard or rather impossible to convince the unix crowd of anything good coming from windows.

There are still tons of stringly-typed interfaces in powershell.

I did not say I am a big fan of the powershell or windows in general. But I would still like the few good ideas integrated into linux ..

Unix being stringly-typed is a huge problem.

For example, I found a flatpak of a system monitor and thought it was portable. Turns out, it parses `ps` output directly, but it's not compatible with BusyBox `ps` output

https://github.com/hakandundar34coding/system-monitoring-cen...

the author literally doesn't care since it works with coreutils `ps`

it's a culture problem

Doesn't ps just parse /proc entries these days? Seems like an odd hill for that dev to die on.

I suggested for him to parse /proc in that issue tracker, but he kind of stopped reading my suggestions

I'd recommend you not look at awk/sed then.

Awk is a real programing language (hint: who are A, W, and K) where short scripts are strings passed in via single arg. That's not find.

Sed has a fairly well designed although limited interface you again pass in.

By contrast find tries to have separate pieces strung together each as an argument.

I got used to `du | grep` after using Plan 9 a lot and still do it on Linux, but yeah really I think Plan 9 fans have had a tendency to ossify the pragmatic minimalism of the Bell Labs guys into a sort of cultishness... there's no reason we couldn't have find on Plan 9, but now it's almost a religious point not to have it.

On the other hand, the lack of find is not a particularly good rebuttal to the original point. If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched?

Realistically yes. But I would still use it.

Would, but don't?

Would complain, and would use it.

> If I rolled up in a prototype personal transport which could go 1000 miles on a single AA battery, would you complain that the seats were poorly stitched?

If the poor stitching were taken as a point of pride and the community refused to fix it, then yeah, I'd assume that that community values purity over practicality. Which is exactly how I feel about Plan 9: it had good ideas and was an improvement over Unix in many ways, but it was a regression in others, in large part due to choosing minimalist aesthetics over usability.

But the fact is that you could get a decent find into Plan 9 in a day's work. Hell, you could probably just compile some existing Go version of find without any changes. Trying to get Plan 9-style namespaces into Linux is not nearly so trivial.

It's not about "find" in particular, that was just an example brought up to illustrate the general point. If "find" was the only thing missing to bring Plan9 up to Linux usability standards, that would indeed be easy to fix.

The big lesson Plan 9 seemed to have learned is that maintenance is a drag and a hinderance. find may be objectively better than du | grep for the user, but once introduced then the developers have to essentially maintain the same thing twice and carry that baggage forever into the future.

In a parallel universe where Unix did not take on so much baggage, perhaps it could have even naturally evolved towards Plan 9 and Plan 9 would have not been a necessary break. But then, like Plan 9, maybe Unix would have never rose up to see any widespread use to make that evolution significant.

Tradeoffs, as always.

I always feel guilty that find . | grep <pattern> is easier for me than remembering how find's flags work. But I think it's really a case of my brain rejecting exactly the redundant baggage you're speaking of here.

What's hard about "find . -regex <regex> -exec <stuff> /;"

Hardest thing that comes to mind is there's some slight portability differences to look out for between GNU find and BSD find that may require a quick man dive with relation to the max depth handling, but that's about it.

Ah...find's "swiss army chainsaw" mode. So, so useful. :)

You just answered your own question because it's "\;" not "/;". And the "{}" placeholder syntax isn't exactly intuitive either (maybe there is some connection to awk or sed? I only know enough of those to be dangerous).

I've used find extensively in the past two decades and even read the man page (gasp) on occasion, but it's one coreutils command that I have always found cumbersome. I recently discovered fd and I have a feeling that I will be switching to that where I can, muscle memory be damned.

> The big lesson Plan 9 seemed to have learned is that maintenance is a drag and a hinderance.

So they chose to just never finish the OS instead.

No, they did choose to finish the OS. The final release came quite a number of years ago.

The thing that I use find for most commonly is to perform a hierarchical grep, i.e

find . -exec grep -Hn regex \{\} \;

How would you do that with the du | grep combo?

... | xargs grep -Hn regex

This will also be faster, because you fork less.

Using \+ instead of \; will do the same (fork less).

du -a will need to do a stat to get the file size, which is comparatively expensive; I don't think find will (not sure)?

You're right, find won't call stat() unless it needs to. It doesn't need to for recursing through the directory tree because readdir() returns dirent.d_type these days to determine if a name is a directory.

Yes, those stat() calls can be very slow in aggregate on a large tree, especially from HDD (due to seeking) or network filesystem, if the stat information isn't already in cache.

Oh, I forgot about \+. I still pipe to xargs every single time.

Does this deal with arbitrary filenames (having newlines, control chars etc) correctly? Or does Plan9 forbid such filenames?

I've never used plan9. In Linux you do "find -print0 | xargs -0" to deal with that.

Im not sure how one can do \0 separator with du, plan9's du(1) doesn't list such option.

grep -R

but old habits die hard :)

The new kid just learned to walk(1).

http://git.9front.org/plan9front/plan9front/HEAD/sys/src/cmd...

329 lines of code.

For nix: https://github.com/google/walk

You can also use dmenu's stest to do the equivalent to find's -type f, { walk $PWD | stest -f }

The walk(1) on 9front seems to have grown up and supports many options: http://man.9front.org/1/walk

Perhaps depends on your definition of “user friendly” - Find is certainly not going to be at the top of my own list. Half the time I use ls -lR | grep because I can’t be bothered to rediscover the right find option - which won’t even do what I want the first time I try it.

Then you can use "find | grep".

Find works without parameters? I don’t think that’s always been the case, and it doesn’t work on MacOS.

In this case, "find . | grep".

I would guess the minimalism was a practical choice at the time, given it was a pretty small team making an entire OS. Had Plan 9 ever become some kind of commercial (or even open source) success, I'm sure a find command would eventually have found its way in.

Yeah find is a bad example for bloat, compared to GNU echo or GNU yes. find AFAIK is mentioned more for horror stories, Bernstein insults, as an example for alien parts of UNIX-like OSes which prevent from a streamlined, predictable-in-your-head experience. "It isn't windows server", a statement which devoids of meaning sometimes with powershell and with Azure cloud apis, but eh.

« To name one egregious example, omitting find(1) in favor of piping du(1) [...] to grep(1) is not an improvement »

I agree, but it seems to me that this is partly because it's stuck in its tiny little niche and never got the rough edges worn down by exposure to millions.

I was a support guy, not a programmer. I started Unixing on SCO Xenix and later dabbled in AIX and Solaris, and they were all painful experiences with so many rough edges that I found them really unpleasant to use.

Linux in the 1990s was, too. Frankly WinNT was a much more pleasant experience.

But while Win2K was pleasant, XP was a bloated mess of themes and mandatory uninstallable junk like Movie Maker. So I switched to Linux and found that, 5-6 years after I first tried Slackware and RHL and other early distros with 0.x or 1.0 kernels, it was much more polished now.

By a few years later, the experience for non-programmers was pretty good. It uses bold and underline and italics and colour and ANSI block characters, right in the terminal, because it assumes you're using a PC, while the BSDs still don't because you might be on a dumb terminal or a VAX or a SPARCstation or something. (!)

Linux just natively supports the cursor keys. It supports up and down and command-line editing, the way Windows does, the way PC folk expect. BSD doesn't do this, or very poorly.

Linux just natively supports plain old DOS/Windows style partitions, whereas BSD did arcane stuff involving "slices" inside its own special primary partitions. (GPT finally banishes this.)

I've taken this up with the FreeBSD and OpenBSD devs, and they just plain do not understand what my problem is.

But this process of going mainstream on mainstream hardware polished the raw Unix experience -- and it was very raw in the 1990s. Linux from the 2nd decade of the 21st century onwards got refined into something much less painful to use on

Plan 9 never got that. It still revels in its 1990s-Unix weirdness.

If Plan 9 went mainstream somehow, as a lightweight Kubernetes replacement say, it would soon get a lot of that weirdness eroded off. The purists would hate it, of course, just as BSD purists still don't much like Linux today.

Secondly, Plan 9 did a tonne of cleaning up the C language, especially (AFAICT) after it dropped Alef. No includes that contain other includes is obvious and sensible and takes orders of magnitude off compilation times. That rarely gets mentioned.

The other vital thing to remember is that despite 9front (and HarveyOS and Jeanne and so on), Plan 9 was not the end of its line.

After Plan 9 came Inferno.

I have played around with both and just by incorporating late-1990s GUI standardisation into its UI, Inferno is much more usable than Plan 9 is.

Plan 9 made microkernels and loosely-couple clustering systems obsolete >25y ago.

A decade or so later, Inferno made native code compilation and runtime VMs and bytecode and all that horrible inefficient 1980s junk obsolete. It obsoleted WASM, 2 decades before WASM was invented.

With Plan 9, all the machines on your network with the same CPU archuitecture were parts of your machine if you wanted.

(A modernised one should embed a VM and a dramatically cut-down Linux kernel so it can run text-only Linux binaries in system containers, and spawn them on other nodes around the network. Inelegant as all get-out, but would make it 100x more useful.)

But with Inferno, the restrictions of CPU architecture went away too. The dream of Tao Group's Taos/Intent/Elate, and AmigaDE, delivered, real, and FOSS.

When considering Plan 9, also consider Inferno. It fixed some of the issues. It smoothed off some of the rough edges.

I feel, maybe wrongly, that there could be some mileage in somehow merging the two of them together into one. Keep Plan 9 C and native code as an option for all-X86-64 or all-Arm64 clusters. Otherwise, by default, compile to Dis. Maybe replace Limbo with Go.

> No includes that contain other includes is obvious and sensible and takes orders of magnitude off compilation times. That rarely gets mentioned.

That seems like an insane concept. I honestly can't see how it can be justified in a world where pretty much every compiler since the 90s has support for `#pragma once` and detects include guards automatically without re-reading the header.

Oh really?

Can you illustrate this with examples? Ones that are from outside of the Unix and C family, just to make it clear that we aren't talking about tweaks to old tools?

Examples of what ? Also, what exactly do you mean by "outside of the Unix and C family" ?

(note: if you want examples of compilers that have `#pragma once` then I don't know what to say because I'd be hard-pressed to name a compiler that does not support it - similar situation w.r.t. header-guard detection)

You said:

> pretty much every compiler since the 90s has support for `#pragma once`

I asked for examples.

Specifically I am asking for examples that are not C compilers, do not compile languages derived from or related to C, and which do not run on Unix-like OSes, because what we are talking about here is what came after Unix. Plan 9 is effectively Unix 2.0: it is what the people who designed and built Unix did next.

Inferno is Unix 3.0. It's what they did after Plan 9.

Tweaks to the project that they had moved on from (or clones thereof, e.g. Linux) are not particularly interesting or relevant in this context, IMHO.

> Specifically I am asking for examples that are not C compilers, do not compile languages derived from or related to C, and which do not run on Unix-like OSes, because what we are talking about here is what came after Unix. Plan 9 is effectively Unix 2.0: it is what the people who designed and built Unix did next.

You want me to cite compilers that don't compile C that support a C extension ? And you want the language it compiles to be completely unrelated to C ?

Frankly, I'd already be quite hard-pressed to even cite a compiler that compiles a language that is completely unrelated to C in the first place and doesn't run on any Unix-like OSes (I guess maybe something like cmd.exe (...though it's an interpreter, not even a compiler) or some assembler written entirely in assembly - I think there's a few I've seen for Windows (though an assembler isn't typically considered much of a compiler) or something like that ? Does Windows even count as "not Unix-like" ? Does Wine mean it runs on Unix-like OSes ?)

This just makes your criteria seem like it can't match any compiler at all, quite frankly, unless you're asking to trawl through truly ancient stuff from the 60s that I wouldn't even be able to test at all in the first place (since by the criteria you've given it must not be able to run on my laptop)

Also, I'll add that you're likely to be correct in the most literal sense - I don't expect many compilers for languages that don't directly descend from C to include anything like `#pragma once`, because they're using a completely different model from C: almost no languages these days use "copy-paste" style file inclusion to handle libraries, and if they do anything like that, `#pragma once` is implied and never needs to be manually specified.

But in practice, `#pragma once` allows C libraries headers to work just like in many other languages - they can freely include other libraries without forcing the user to do so themselves manually.

Just imagine if you had to follow the Plan 9 C scheme on other languages, imagine if everyone that did `import argparse` in Python had to then add `import os`, `import re`, `import gettext`, `import warnings` and `import sys` because `argparse` can't do it itself without fear of double inclusion (...and then you'd also have to manually add `import abc`, `import stat`, `import enum`, `import functools`, `import unicodedata`, `import copyreg`, `import posix`, `import posixpath`, `import nt`, `import ntpath`, `import subprocess`, `import io`, `import locale`, `import builtins`, `import linecache`, `import tracemalloc`, `import traceback`, `import types`, `import operator`, `import reprlib`, `import collections`, `import weakref`, `import typing`, `import genericpath`, `import pwd`, `import errno`, `import time`, `import signal`, `import threading`, `import contextlib`, `import fcntl`, `import msvcrt`, `import select`, `import selectors`, `import grp`, `import encodings`, `import tokenize`, `import fnmatch`, `import pickle`, `import itertools`, `import textwrap`, `import keyword`, `import atexit`, `import gc`, etc. as the nested dependencies of os/re/gettext/warnings/sys/etc.)... I can't imagine anyone would consider that a good thing.

Thanks. You inadvertently completely confirm the point that I was seeking to validate.

> You want me to cite compilers that don't compile C that support a C extension ?

No.

There are, hmm, I am not sure, at least 2, probably 3, and I suspect more than 3 assumptions in here.

#0, general context:

The bigger picture here is that there is a whole world of OS and language development which is completely outside the world of Unix, C, and things that derive, directly or indirectly from it.

However, the Unix+C world is so big, so commercially successful, that a lot of people in it can't see that there is anything else. To quote Gaiman and Pratchett, it's the same as the reason that "people in Trafalgar Square can't see England".

I wrote about this recently: https://www.theregister.com/2022/03/29/non_c_operating_syste...

#1. Plan 9 is not a Unix. It's what came after Unix. As such, I would say it's fair to say that Plan 9 C is not plain ol' Unix C. While the Unix flavour of C has continued on its own path, it's a very conservative path: it's terrified of breaking backwards compatibility. The developers of Plan 9 were not scared like this, and quite cheerfully made big sweeping changes.

#2. So, yes, I would consider that carefully implementing and adding what you yourself call an extension to an existing compiler (or set or family of compilers, it doesn't really matter) is not the same thing as redefining the semantics of a language to say "you are not allowed recursive includes".

One is a big sweeping change; the other is a minor tweak.

#4. The core, important point here is that Plan 9 made significant changes which in places have big ramifications — for instance, performance improvements on the order of several orders of magnitude — simply by tightening up the rules around an existing, well known language. IMHO, adding a new compiler directive is not comparable to this.

Adding a new directive is patching a hole, while changing the rules of how the languages compiled is fixing the design. What I was enquiring about was other designs that fix this problem in the core design of traditional compilers, in other words UNIX C and its descendants.

> And you want the language it compiles to be completely unrelated to C ?

Well, yes! Why not? There are lots of them!

> Frankly, I'd already be quite hard-pressed to even cite a compiler that compiles a language that is completely unrelated to C in the first place and doesn't run on any Unix-like OSes

Really? OK then, let me see how many I can name of the top of my head without googling: Pascal, Lisp, APL, Fortran, Cobol, Algol, BCPL, Forth, Ada, Prolog, Bliss... Okay I'm starting to struggle a little bit now, but I think the point is made.

I wasn't asking for languages that don't run on UNIX. I was asking for languages that weren't built out of UNIX tools. There are legions of languages today that were built pretty much entirely from the existing UNIX toolchain, from Python to JavaScript. My point is that there are dozens to hundreds of languages which are outside of that family.

Plan 9 is, I would argue, outside of that family because it's what came after that family.

Operating systems from outside of the UNIX family? Classic MacOS, AmigaOS, CP/M, MS-DOS, Atari ST TOS, Concurrent CP/M, Concurrent DOS, DR FlexOS, Novell Netware, OS/2 and all of its descendants, GEOS, Palm OS, Newton OS, Microware OS9, Interlisp/Medley, OpenVMS, OpenGenera.

And of course basically all mainframe operating systems... Tools that are still worth billions of dollars today, whose daily use affect everyone who uses a bank account or everyone who ever travels on an aeroplane.

So, yeah, a pretty significant technological and economic market segment… and one that UNIX people often totally forget exists at all. As it seems you did.

> I wasn't asking for languages that don't run on UNIX.

That sure is quite a useful precision to make - personally I found what you were asking for confounding given I can't really think of much of any language that doesn't run on UNIX, save for particularly obscure, often long-defunct ones (i.e. languages that basically don't run on anything at all or on stuff I couldn't possibly check out myself anyway). The fact you've also implicitly added the stipulation that only languages that derive from C and not all those that are related to it are excluded is also quite useful - I was excluding languages like BCPL or Algol on that basis (and I was quite iffy on Fortran/Pascal and a few others too, though since most ran on UNIX I wasn't even considering most of them anyway).

Also, while I broadly agree with your point about most people not even thinking stuff outside of Windows/UNIX exists and indeed find it quite acutely accurate in many cases, I'd say I'd hope I wouldn't be counted in it - I could have named most of the OSes and languages you did, save for a few like Microware OS9 or Bliss, simply I did not name the languages when prompted to because I'm not really aware of any that can't run on UNIX-like OSes, which I had then thought you were excluding before you clarified things.

Anyway, I'm aware of my ignorance of many of the details that are involved, but more importantly for what we were discussing, I would find it remarkably unlikely that any of these languages has a dependency handling system quite alike to that which is involved in Plan 9.

Are you actually telling me that you know of many examples of languages and/or compilers that handle dependencies like in Plan 9 ? That want you to manually specify all the dependencies of all the libraries you want to use before you can use that library, and which consider this sane in any way ?

If any actually exist, then I'd expect there's either: 1. Tooling around them specifically made to work around this exact issue by automatically specifying the dependencies when needed without having to spell them out manually 2. Preferred alternatives that don't have this problem in the first place

Meanwhile, the `#pragma once`-style model (i.e. make it so that imported libraries can use a separate library without ending up with asinine "double definition lol" errors if the program that uses the first library also separately uses the second one) seems like the evident standard that all the other languages use, such as:

- Ada

- Fortran

- Pascal

- APL

- Cobol

- Algol

- Prolog

within which I've found no examples of needing to do something like `import definitions_every_single_library_or_module_relies_on` and `import definitions_from_the_library_almost_every_single_other_library_or_module_uses` at the top of almost every file.

I am genuinely glad it was helpful!

In general, what I am getting at is that Unix is a (?) uniquely weird situation that happens to have grown like Kudzu. It's an early generation of a long running project, where that early generation caught on and became massive and thus ignores simple but profound improvements from later versions of the same project.

And since in that ecosystem, almost everything is built on a foundation of C, problems with C affect everything layered on top... even though they do not in any other ecosystem. But something like 99% of inhabitants of the ecosystem are not even aware that other ecosystems even exist, let alone knowing anything about them.

If they know of any, it's macOS or Windows. macOS is also UNIX, and modern Windows is NT, which is Windows built with Unix tools and a Unix type design... so they are not really different at all.

So what I am getting at is that Plan 9 has aspects other than the namespaces and the cosmetic aspects of the design. It makes changes to the language and how it's compiled that are just as important, and hacks to gain some of that on modern versions of the parent OS family are not of comparable significance.

Famous quote:

So... the best way to compare programming languages is by analogy to cars. Lisp is a whole family of languages, and can be broken down approximately as follows:

* Scheme is an exotic sports car. Fast. Manual transmission. No radio.

* Emacs Lisp is a 1984 Subaru GL 4WD: "the car that's always in front of you."

* Common Lisp is Howl's Moving Castle.

Comparison: if somehow you make a pruned-down Howl's Moving Castle, you can probably never ever, whatever you do, no matter how much effort you invest, make it into something as small and light as the Subaru, let alone the sports car.

In more detail:

Let's imagine one team invented first the train, then the bicycle, then the car.

The bicycle takes the idea of a wheeled vehicle from the train but reduces it down to an incredibly minimal version. It needs no fuel, just 2 wheels, but it is very simple, very light, and can go almost anywhere.

Although you do need 1 per passenger, it's true, whereas a single carriage train can carry 100 people, you can make 100 bicycles for those 100 people with fewer materials than that 1 train, even excluding consideration of the rails etc.

If someone still making trains looked at bicycles and inspired by them came up with a train with just 2 wheels, that balanced or hung from the track, they do not get to claim that they have successfully imported the simplicity of the bicycle.

They have retained just one aspect and may have achieved savings in moving parts, or slight reduction of complexity, or a slightly simpler machine... but it's still a train.

If you tweak a conventional C compiler to not waste time rereading text that has already been read once, or a disk cache obviates it, then you have not caught up with the advance I am trying to discuss here.

For clarity, this is not my original thinking. This idea is from a Go talk over a decade ago:

https://go.dev/talks/2012/splash.article#TOC_5.

Personal experience: find gets hard to use, and I always have to resort to piping into grep anyway. Maybe I should learn how find works; maybe I should just stick with standard tools. And if `du | grep` gets too long to type, especially with arguments, then that's where I write a script for my common use.

> Rust's "fd" implementation is under 7,000 lines of code

Not counting the 23.8k files, not even lines of code, of rust (https://github.com/search?q=repo%3Arust-lang%2Frust++languag...). Comparison should happen on a similar baseline

I once saw Plan 9 described as "Imagine if all the stuff they told you about Unix was true."

Edit to add: I don't know that this actually makes Plan 9 better, but I'm pretty sure it doesn't make it worse (Although from our perspective in 2023, it's definitely alien and difficult)

Plan 9 had many improvements over Unix of its times. It opened up too late to conquer the world though. Some good things from it were imported into Solaris and Linux later.

Technological progress likes to reinvent itself, looping back to the same idea that did not work last time, and maybe making it a hit finally. Two examples:

- Apple Newton, 1992 (a flop) -> Palm Pilot, 1997 (niche success) -> Apple iPhone, 2007 (world domination).

- Java Virtual Machine, 1994 (server-side world domination, a flop in the browser) -> Inferno OS, from the makers of Unix and Plan9, 1996 (a flop) -> WASM (prospects of world domination in the browser).

I personally don't like WASM. I think the Native Client (which is more than a decade old today) was a much better technical solution. It used actual cpu native assembly bundled with a verifier, and had actual good integration into low-level platform APIs like graphics, threading, etc. instead of using this weird Javascript bridge approach. Due to it being native code from the start, it also had none of the startup performance issues, that plague WebAssembly.

WASI also seems like a wrong approach, considering it inherits the limitations of WASM, like problems with memory, allocation and multithreading and hacks needed to overcome them.

VM-s are also kind of a wash for me too, since nowadays the most popular way to run software in a portable/sandboxed manner is Docker, which is NOT cpu-agnostic, even if you ran a JVM app in it, the bundled JVM would be CPU arch dependent.

Actual CPU native assembly? It would need to support x86, x64, and aarch64 by now. (And likely RISC-5 in the near future.)

The point of VMs like WASM is not (specifically) performance though, even if performance is desirable. It's the minimal, fixed standard, and the isolation.

If you badly need native performance, develop a native application %)

Or it could get translated to the target ISA by the user-agent Rosetta-style, suffering the same warmup issues, but only on some architectures.

Yeah, actual native assembly. I think doing a cross compilation for 2 architectures (x64 and aarch64) is more than doable, even 4, if you want to be thorough.

> The point of VMs like WASM is not (specifically) performance though

I feel like it is though. There was another thing, called asm.js back then, which was a subset of javascript that was easily translatable to machine code. It was a giant hack, and performed worse than NaCl.

I feel like WASM is more of a spiritual successor of that thing.

> If you badly need native performance, develop a native application

And pass up the ease of distribution/compatibility browsers offer?

> world domination

No. Android won. The concept from iPhone won, but Android it's the world leader.

Yes, I mean the concept, the approach.

Unix as a concept (a set of ideas and interfaces) achieved world domination, but it's not the original AT&T kernel, and not the original AT&T userland.

When you say Inferno led to WASM, is it just conceptual or is there a concrete link?

It's not even conceptual.

It's an entirely separate, kludgy and vastly inelegant, reinvention of a concept that had already been done much better.

First in Tao Group's Taos, later much refined and improved in Elate and Intent.

Then done in a more Unixy way in Inferno.

Inferno embeds the cross-platform runtime VM right into the kernel and makes it the default.

WASM bodges a cross-platform runtime VM together out of chunks of web browser and Javascript tech, and then others rip it out of the browser and make it run standalone.

There is basically none Javascript tech in WASM.

As I understand it, and I could be wrong, the origins of the project lay in trying to target the output from a compiler to a bytecode like intermediate language that the JavaScript runtime could execute. I am more than happy to believe that no trace of that is left now, but I think that is more or less how it got started.

Inferno did not "lead" to WASM. Palm Pilot did not "lead" to iPhone.

Instead I'm trying to show the same general idea tried over and over, at different times and from different angles. The arrows just show the sequence in time.

Can't everyone design a better OS than the current operating systems? More features, easier to use as a user, safer, easier to write programs for it, less bugs, more compatibility, etc. I am using operating systems for years, and I have ideas how they should work on the surface.

But it will be slower, and won't have any useful software written for it, also you won't be able to use internet or your GPU. (To be fair several years ago I tried the HURD distribution ArchHurd. I just installed on it on my laptop, and by luck internet just worked, and had a firefox running so it was good.)

edit: probably I did not even install it, but it was a live system.

And then replies slowly devolve into arguing about irrelevant things that were solved with the existence of Linux because plan9 sucks and Linux is just a kernel which is actually used by people and therefore they actually found ways to solve problems they were most annoyed by.

All these "X is poor man's Y" are a cope. Plan9 is poor man's <insert any operating system that is supposedly inferior to Plan9> because noone uses it. I'm sure on most people the irony of this statement will be lost, so I'm gonna explain: yeah, plan9 is better on paper, too bad we live in glass world.

Plan9 is the perfection of a dead end.

But what about security?

I haven't really used it but from what I understood at first most of it is very elegant because at the time it was developped all nodes in a network could still be trusted.

Never tried but I remember reading it was very dependent on the mouse. I probably wouldn't like it.

It is, but for what it's worth using the mouse is much more pleasant than what we're used to ime. It's weird at first, especially with the teleporting thing but it works really well.

Also, if you're gonna try it do it either with a proper three-button mouse or with a large-ish and easy to press scroll wheel button. Otherwise it's really frustrating.

Just the idea of context switching from mouse to keyboard is so annoying to me outside of graphic editing. I installed vinium for firefox recently and it has been a game changer.

That's fair and I share the sentiment to some degree, especially in "regular" systems. In the time period I used plan 9 I quickly got used to it though, and the method of interaction made me a bit slower and much more considerate. I liked it a lot. I still miss it. I'll probably try it again some time.

Context switch??

After longer usage you do that without any thinking

Ish. Just changing where you are oriented can impact how some people are thinking. By nature of their orientation.

Moving to a mouse primes my brain to start thinking spatially about things. Which is not something I'm typically doing when looking at textual/symbolic things. I can see some value in doing it, of course.

One problem I had is that I often just messed up the buttons, especially in the chords, and there's not a whole lot of feedback. I also messed up some things like letting go of the mouse button too soon by accident. Granted, I never spent that long with it, but it's not very mnemonic and requires some amount of motor skills I don't seem to have (e.g. in Vim "dw" is mnemonic for "delete word" and you get more feedback).

Plan 9 in general seems very much like a system "by the designers, for its designers" with not all that much attention to user-friendliness. To some degree that's also the case for Unix, but with Unix other people took the thing they made at Bell Labs and made it somewhat user-friendly (and even then, its received plenty of criticism for it). In Plan9 that step never really happened.

I learned the chords very quickly, but everyone works differently. What kind of feedback exactly would you expect from it? I can't immediately think of anything that would make it much better. I guess animations could help, but then they might just be distracting.

I think the main thing people get confused by besides the chording is the teleporting of the cursor, but then you realize it's actually really useful once you get used to it (at least I did).

> What kind of feedback exactly would you expect from it?

I don't know exactly; this is one of those things where I'd have to implement some things and play around to see what works. Something like some text popping up maybe? I don't know. More advanced users can always just disable these sort of things (I also set up my Vim to not show "-- INSERT --" because at this point it's never helpful for me and it looks a bit nicer this way, but obviously for loads of people it's a very helpful thing).

Fair enough.

A cursor change on the beginning of the chord would be the most obvious feedback. Maybe something like [1-] over the cursor, showing up the pressed key?

>Plan 9 in general seems very much like a system "by the designers, for its designers"

It definitely is that. That's a really great thing when the designers needs and assumptions match your own, but if they don't, you end up wondering what these bozos were thinking.

For what it's worth, Rob Pike was a big proponent of the mouse-driven design, and he has some very thoughtful essays/articles/emails about why he feels that way. I can't say I agree with him 100%, but it's clear that the decisions weren't arbitrary.

Yes, Plan 9 made some bad choices in retrospect, at least in my opinion. The big dependency on the mouse is one of them but also assuming people will be in managed networks.

Article mentions that Plan9 missed `cgroups`, QoS.

Linux moves towards massive process sharing, and thus various of sharing controls are key to the future that is missing from 90s operating systems.

Just enable sound, run your browser and music app, and count number of processes living with `ps ef|wc -l`. I see 282 kernel threads, and 536 total processes. You will see that we live in the future, because of extensive modularization of system services, and cannot get back without sacrificing reliability and comfort.

It doesn't need cgroups or containers, because every process has its own namespace, its own view of the network-global filesystem, so everything is in a container by default.

It doesn't need a microkernel, because the concept of microkernels is to split a big monolithic kernel into lots of small simple "servers" running in user space, and have them communicate by passing messages over a defined communications protocol, some kind of RPC type thing. It works, and QNX is the existence proof. But it's really hard and it's really inefficient -- of which, the HURD and Minix 3 are the existence proofs.

So most of the actual working "microkernel" OSes kludge it by embedding a huge in-kernel "Unix server" that negates the entire microkernel concept but delivers compatibility and performance. Apple macOS and iOS are the existence proof here. (It could be argued that Windows NT 4 and later are also examples.)

Plan 9 achieves the same result, without the difficulties, by default by having most things user space processes and communicating via the filesystem.

Disclaimer: this is my very rudimentary understanding. I am not an expert on Plan 9 by any means.

Cgroups are a lot more than just "namespaces". It is also the mechanism by which you can constrain how much CPU, Memory, Network Bandwidth, Storage IOPS or Throughput, etc., processes in a particular cgroup or container can use.

That's fair.

But I think the core point here is that, as with much of the Plan 9 design, by including a more elegant and powerful abstraction in the core design, the need for a much more powerful and much more complicated abstraction layer on was obviated, if not eliminated.

It didn't have cgroups, because at the time it was thought of as a distributed system meaning it would run a single service, authentication for example, and there was no real ability to share resources in the way we do today.

Remember CPUs were largely single threaded, and you had expensive multi-cpu systems that ran 2, 4, and 8 CPUs. Compute heavy processes consumed entire systems, or CPU since SMT was also not common. You couldn't effectively microsegment CPU usage, because you were only really multiplexing idle time. Additionally, your OS had to consume more cycles to do that resource sharing.

Today, the story is pretty similar, but we have systems with multiple cores, and SMT. We can share resources more effectively, but its also that our systems have 16x more scheduling slots.

Yeah when you look at REST vs GraphQL and realize it’s all just streams and namespaces plus some conventions - you get the generality of Plan 9 again.

Did it live too far in the future for the time?

Just as its sucessor, Inferno.

Which is what ChromeOS and Android are mostly today, leaving C to the kernel, or tiny special purpose libs, and everything else in a managed language, Limbo.

And how close is Go to Limbo?

If I remember correctly, they have similar concurrency models. They were both written the same author as well, Rob Pike.

Edit: fixed a typo

Quite close, unsafe package and method declaration come from Oberon-2 (thanks Robert Griesemer), everything else is somehow inspired from Limbo.

https://www.vitanuova.com/inferno/limbo.html

https://www.vitanuova.com/inferno/docs.html

The same person who is involved with Plan 9 also made Go. Taking one look at that programming language doesn't leave me very optimistic about Plan 9.

Agreed. Go is a shining example of Unix philosophy - but I don't mean that as a compliment. I mean it prioritizes ease of implementation over any other concerns and hence forces the user to reinvent many wheels. Forces round things into square holes, regardless of if that interface actually makes sense. And either completely ignores good ideas from other camps or goes sour grapes and claims they're overcomplicated and bad (then quietly tries to hack them on later)

Worse is better than nothing, but when better has been demonstrated to exist, worse is just worse

I remember trying to figure out what's up with Go and left in complete disbelief when I was told that I need to install nginx on my local machine and fake a DNS entry just for go's package manager to "fetch" my local package from my local machine just so I could mess around with it how that works.

All because I couldn't care less about 3rd party services like github.

User error.

you're holding it wrong

That's never been and still isn't mandatory

> The same person

Go was designed by:

- Robert Griesemer, known for nothing else,

- Rob Pike, primarily known for sam(1), acme(1) and several other Plan 9 tools, the Blit (Unix's own graphical terminal), UTF-8 (with Ken Thompson), Inferno and Limbo,

- and Ken Thompson, ancient god.

All these things you listed are objectively bad and a tumor and I'm glad that those that are gone, are gone for good, because the one that stayed is a menace to any programmer caring about his sanity.

What's wrong with Acme?

I only have two hands.

That's a reason to switch from Emacs to Acme. ;-)

Bad how and why?

I mean, as editors, for instance, Vi and Emacs are horrible ugly things that were rendered obsolete by the Apple Lisa in 1982, let alone by the mainstream success of the Mac a couple of years later.

And yet, they persist.

X11 is a horrid lashup for what most people actually use it for. And yet, it remains way more mainstream than Wayland, say.

Well... https://dreamsongs.com/WorseIsBetter.html

100% this, yes.

> Vi and Emacs are horrible ugly things that were rendered obsolete by the Apple Lisa in 1982

Disagree. In the vi/TECO model and emacs to a slightly lesser extent, you operate on text, using text, with an input device that has a 1:1 mapping to units of text. In the Lisa model, you operate on pictures of text.

I think that you misunderstand my point here.

As far as the UI goes, the critical distinction is not about how it looks on screen or how it is rendered, it's about modal versus nonmodal user interfaces. I happened to side with Larry Tesler on this: "don't mode me in!"

As far as Emacs goes, I was more thinking about its strange set of user interface conventions and terminology, which pre-date (and conflict with) industry standards such as the IBM CUA set of standards which came to almost completely dominate DOS, Windows, and Linux.

How the appearance of the thing is rendered on the screen is completely irrelevant to this.

All text editors are modal editors though, all text editors have a command mode and an input mode.

In (q)ed/ex/vi and their direct and/or spiritual successors, you'll reach Command Mode by pressing Escape. In Emacs, it's Ctrl/Alt/Meta. In Acme, it's the mouse. Even editors which (almost?) follow the CUA standards have a Command Mode - using the Ctrl modifier key.

I think that may be over-generalising a point into irrelevance.

All editors have commands of some kind, yes. Otherwise, it's not an editor.

But holding down a modifier key is not a mode in the software. You could sort of argue it's a mode of the keyboard,. or of the key, but I think it's over reaching.

I've seen editors with no menus, no visible UI at all, just hotkeys that do stuff. It is still a UI even if it is not visible. There are apps for blind Windows users with no visible presence on the screen at all, such as the Qwitter Twitter client.

If pressing the Ctrl key suddenly made the app switch into a different type of operation until you pressed it again, that might count, but it doesn't. The app doesn't even need to know. It just knows "keycodes #F to #Z enter letters, but #A to #E are commands". There are no modes here.

I’m not even sure if the point IS relevant at all. The software-side difference between “the user pressed I, am I in command mode?” and “the user pressed I, did he also press Ctrl?” is not that big.

Granted, one is Shift and one is Caps Lock…

The point is hugely relevant.

It's like saying that cars, motorbikes and bicycles were irrelevant, because trains already existed.

A lot of terminal driven software design pivoted around lots of modes. Input mode, edit mode, command mode, extended command mode, etc etc etc. It's powerful but it's very hard to learn and everything becomes very context sensitive. What any key or instruction does depends heavily on what you did before.

That means you have to remember. That means you have to think much more.

The design of second generation GUIs (the Apple Lisa etc.) strove hard to eliminate this totally. The user can do anything at any point without modes of interaction.

The pivotal event that is often missed, and much of the Unix industry even today does not get, is that in the years after the Lisa and the Mac (and, don't forget, their affordable cousins such as the ST, Amiga etc.) appeared, that this stuff then filtered down to DOS and revolutionised DOS apps too.

And those (DOS and DOS apps) were the commercial mainstream, and that ecosystem is what evolved into Windows and all modern computers. Yes including the ones running Linux, and including Linux at the GUI level.

The Mac now is a descendant of NeXT, and is a Unix, remember. It's unrelated to Classic MacOS.

But the UI design of the GUI layer comes directly from Apple R&D. The UI at the shell layer comes from a decade or 2 earlier and is totally different.

Unless you know this, the differences between Unix' and Windows' GUIs and shells makes little sense.

Windows modernised its shell layer.

Unix didn't.

Are you including UTF-8 in "those things" that are "objectively bad and a tumor" ?

Before Go, Robert Griesemer worked on:

- Strongtalk: https://www.strongtalk.org/history.html

- Object Oberon: https://en.wikipedia.org/wiki/Object_Oberon

- Sather: https://www.gnu.org/software/sather/docs-1.2/tutorial/intro2...

This is the first time I've heard about any of these. Thank you!

> The same person who is involved with Plan 9 also made Go. Taking one look at that programming language doesn't leave me very optimistic about Plan 9.

Hilarious how in any thread on HN tangentially related to Go, somebody will inevitably find a way to construct that bridge to Go purely to shit on it (and it's rarely anything more interesting than "Go sucks, right?").

It is almost our duty as citizens to throw shit back at the Google marketing machine.

Reply on news.ycombinator.com