I can’t speak for everyday workflow (having discovered this project less than a week ago), but rebase being unnecessary and cherry-pick not creating duplicate commits seem like the most notable advantages to me.

There’s an argument to be made that system software like filesystems and kernels shouldn’t get too smart about validating or transforming strings, because once you start caring about a strings meaning, you can no longer treat it as just a byte sequence and instead need to worry about all the complexities of Unicode code points. “Is this character printable” seems like a simple question but it really isn’t.

Now if I were to develop a filesystem from scratch, would I go for the 80% solution of just banning the ASCII newline specifically? Honestly yes, I don’t see a downside. But regardless of how much effort is put into it, there will always be edge cases – either filenames that break stuff, or filenames that aren’t allowed even though they should be.

The usual problems with parsing ls don’t happen here because Nu’s ls builtin returns properly typed data. You can work with it in pretty much the same way you would work with it in Python, except that Nu has a composition operator that doesn’t suck ass (|), so you don’t have to write as much imperative boilerplate.

I have a number of reservations regarding Nu (the stability of the scripting language, unintuitive syntax rules, a disappointing standard library) but this particular argument just doesn’t apply.

One thing that bothers me about Nushell (even if it doesn’t really matter) is honestly just how bloated the table style is, with three columns in each column margin and six columns of enforced line numbers. Why can’t it display tables in the same style as regular UNIX commands?

Another thing that bothered me is that the “blessed” way to parse tables from external commands seems very fragile to me. Iirc the builtin parsing commands work solely off table headers, which are locale dependent for many commands, so a script might appear to work fine but suddenly break if an LC_* environment variable sneaks in somewhere. The size filter trick works nicely for ls, but doing the same thing becomes painful again when using df.

I also found the script syntax (implicit line continuations, command seperation, etc.) difficult to understand but presumably that’s just a matter of familiarity.

I’ll have to give it another try in the future but for now Fish is good enough for me.

No C program is written to satisfy a borrow checker and most wouldn’t compile with one, so adding it would require rewriting the world anyways. At that point why not choose a language that, in addition to being memory safe, also drastically cuts down on other kinds of UB, has sum types, sane error handling, a (mostly) thread safe standard library, etc.?

To be fair this also happened to Eagle Dynamics, developer of DCS, the other “realistic” flight sim that players take far too seriously. Except there it was a Dev that got arrested in Georgia and extradited to the US…