The Case for Nushell (2023)

https://www.sophiajt.com/case-for-nushell/

by ravenical • 7 months ago

67 71 7 months ago

xpe7• 7 months ago

A nice coincidence to read this; I was just telling some friends the following (lightly edited):

Nushell is amazing and a total pleasure to use. I cannot yet discern any limit to how much thought has been put into it.

I’m stunned in a good way. I’m writing shell scripts without any pain — actually I much prefer them to Python! With the language-server integration – I use Zed, but I'm sure they exist in VS Code and others too – I can see errors in scripts as I write them! (Including typos in pathnames! Amazing.)

I have to admit Nushell didn’t become my daily driver right away; it took a few years for me to switch fully. I don't know exactly why, but it probably had to do with its lack of POSIX compatibility. I now see this as a necessary break for Nushell to pursue its vision.

About expectations: some people will be delighted immediately and get hooked, but not all. We're all busy and adopting a new tool can feel like a leap of faith. For me, it has been worth it. Nushell has felt like planting a garden that gives back way more than you put into it.

I wrote up a quick gist [1] that shows how nice the experience is to write a new command (i.e. function) in Nushell.

[1]: "Building Argsort with Nushell" https://news.ycombinator.com/item?id=46528644

xpe7• 7 months ago

From an end-user point of view, there are some weirdnesses in Nushell, but they are rare in my experience. Here is one that gotcha'ed me:

    [1 2 3] | sum

The above does not return the sum (1 + 2 + 3 = 6). Why? Because `sum` is a *nix utility for returning the checksum. The way to do it in Nushell is:

    [1 2 3] | math sum

More info at [1]. Technically, this isn't Nushell's fault; it is just delegating to an external command.* Still, I found it confusing at first.

* Maybe it is time to rename `sum` to `checksum`!

[1] https://github.com/nushell/nushell/discussions/17239

Natfan4• 7 months ago

i've never used nushell, but i've always felt that people have been sleeping on PowerShell.

yes, it was _originally_ only for Windows, but PowerShell 6+ uses .NET Core, which is OS independent. this means that a few helper functions like GeneratePassword[0] are gone, but it's _mostly_ at parity with .NET.

the Verb-Noun structure can be confusing at first, but once you know the approved verbs[1], you can usually guess your way through command discovery, which is not something i can say for most POSIX tools (useradd and adduser do different things!!)

it's also object oriented by design, with default aliases like ?[2] and %[3], querying structured data is a breeze.

- want to check a CSV? Import-CSV[4].

- want to call a REST/SOAP endpoint? Invoke-RestMethod[5] has you covered.

- DNS queries? Resolve-DnsName[6]

as it's built on top of .NET, you get the whole CLR[7] at your fingertips! you can make a TCP client[8] in PowerShell, or even just write C# directly in your terminal[9] and execute it the same way.

such a flexible and useful language, even if it is a little slow and owned by micro$oft. but it _is_ open source[10]!

---

[0] https://learn.microsoft.com/dotnet/api/system.web.security.m...

[1] https://learn.microsoft.com/powershell/scripting/developer/c...

[2] https://learn.microsoft.com/powershell/module/microsoft.powe...

[3] https://learn.microsoft.com/powershell/module/microsoft.powe...

[4] https://learn.microsoft.com/powershell/module/microsoft.powe...

[5] https://learn.microsoft.com/powershell/module/microsoft.powe...

[6] https://learn.microsoft.com/powershell/module/dnsclient/reso...

[7] https://learn.microsoft.com/dotnet/standard/clr

[8] https://learn.microsoft.com/dotnet/api/system.net.sockets.tc...

[9] https://devblogs.microsoft.com/scripting/weekend-scripter-ru...

[10] https://github.com/PowerShell/PowerShell

b40d-48b2-979e• 7 months ago

As a prior contributor to PowerShell, I think part of this obscurity reason is how they neglected their community. This was evident in their merged PR history only containing commits from Microsoft developers.

I use nushell now, and its community is fantastic. It may face breaking changes every so often, but it has a much faster execution speed and more features if you're not tied into the .NET ecosystem.

Natfan4• 6 months ago

that's completely fair! i've never felt the need/confident enough to attempt to contribute changes to the language as a whole (writing my own PowerShell is usually enough to fix the problem c:), but i can understand why that would be frustrating!

adzm• 7 months ago

Powershell is pretty great, though I am constantly bit by issues with filenames having [ or ] in them and end up having to pass -LiteralPath to everything, which is frustrating and a constant source of bugs in any other scripts that do not do that.

Natfan4• 6 months ago

can you not just quote the filepaths? either as a 'literal string' or as one with "string $interpolation" (provided you have no dollars in your file names)

acedTrex• 7 months ago

I really wanted to get into nushell but i found reedline to be very limiting in a few specific ways esp around keybindings that blocked me from moving to it

cassepipe2• 7 months ago

Anyone knows how good is the vi mode ?

adamnemecek• 7 months ago

I started using nushell around April 2024. While it is much better than other shell languages, the lack of proper types is painful.

Shell languages make sense if you believe in the Unix philosophy. For me, the problem with the Unix philosophy is the endless serialization and deserialization as well as lack of proper error handling. So nushell for me is a good answer to an ill-posed question.

The approach I have been taking is a single binary with a billion subcommands and aliasing these. I currently have two of these in Rust, one in Swift. I tried going all Rust but integrating with certain aspects of macOS is just so much simpler in Swift.

Like the recent push to make CLI development suck less (e.g. argument parsing used to be painful but is solved now) has made developing CLI tools a lot less painful.

nialv7• 7 months ago

serialization/deserialization will always be needed unless you got all your programs working with the same ABI. it's just that in nushell's case you aren't serialize to human readable text.

UltraSane5• 7 months ago

endless serialization and deserialization is what makes me hate Bash and love PowerShell which solves this issue by piping full objects between commands and the ConvertTo-JSON command.

BadBadJellyBean4• 7 months ago

I have always struggled a bit with shell replacements. I use zsh but only because of oh-my-zsh. Apart from that I always thought of shell scripts as a necessary evil for interoperability. Today you can usually expect a linux system to have bash or at least sh. That is why I do shell scripting. Nushell is usally not preinstalled on a system and so I cannot expect it.

If I want to do real scripting/programming I use python or another dedicated programming language. I don't really know what the value of Nushell is for me. Maybe the plugin system is amazing but at the moment I miss nothing in my zsh.

timeon• 7 months ago

It is not just about scripting but the structure of input and output. Also no need to give up (z)sh switching shells is eazy.

BadBadJellyBean4• 7 months ago

Maybe I need to get into nushell more but my feeling is that if it's a simple problem it the benefit will be negligible and if it is too complicated for that I will probably write a python script.

mmh0000• 7 months ago

I really would like a new shell that wasn't based on a poorly designed programming language from the 1960s[1][2]

However, I need to know sh/bash well because they're the tools installed by default; in any "well-established" organization, getting approval to install a new shell will range from "12 to 24 months" to "impossible". And without that, I'm not going to put in the effort to learn a new tool that is only useful some of the time and requires massive context switching.

[1] https://en.wikipedia.org/wiki/ALGOL_68 [2] https://en.wikipedia.org/wiki/Bourne_shell#:~:text=Stephen%2...

BadBadJellyBean4• 7 months ago

That's what I mean. A new shell would need to blow me away with some amazing must have interactive feature. The scripting part is, at least for me, not really relevant. If I can install software on the target I will install a proper language and if not then it will be bash or sh anyways, even though they properly suck.

xpe7• 7 months ago

We all know the dueling aphorisms of "if it ain't broke, don't fix it" versus "no risk, no reward", so I'll just say this: there is a middle way. I keep a whole lotta Zsh and Bash scripts. But for work on systems I control, Nushell is a boon. I use it for interactive work and add scripts when I see a need.

piekvorst3• 7 months ago

Python is good for general-purpose scripting, which does cover most of the tasks, but it’s still too bureaucratic when it comes to OS primitives. And when a small script at hand is tightly related to some OS thing anyway, it’s not a disservice to write it in shell.

csmantle• 7 months ago

Python's main distinction from a shell scripting language is that external program invocations are not first-class citizen. Also no easy ways to feed/read the subprocess's std io.

ndsipa_pomu• 7 months ago

The example FOR loop in BASH is missing a trick to make it easier to read:

  for i in {1..10}; do
    echo $i
  done

(Though I prefer using printf than echo as it's more capable and POSIX compliant)

I write far too much stuff in BASH, but for me it's just not worth moving to using a different shell due to its ubiquity. There's also the question of "will this still run easily in 20 years". Of course, BASH is a nightmare for bugs and foot-guns unless you make a point of defensive coding (e.g. surround variables with double-quotes and using Shellcheck to point out common errors).

By the way, the article goes on to mention the large number of options to "ls". Don't try to parse the output of "ls" in scripts as there's better ways to do things: https://mywiki.wooledge.org/ParsingLs

tormeh2• 7 months ago

If you're ever forced to use Windows, just install nushell. The speedup is wild, and along with it comes many nice quality of life features.

Nushell is good on the Unixes as well, but the defaults there are less annoying. I regularly revert to bash because there's just some thing I've memorized in bash, and bash doesn't make me want to scream.

Note that this is just my perspective on it as an interactive shell. I've never used it for scripting.

UltraSane5• 7 months ago

Windows already has a very good shell called PowerShell.

tormeh2• 7 months ago

I've tried the stock Windows shell and utilities. `ls` is noticeably slow in directories with like 15 subdirectories. That's not acceptable. Even the terminal emulator is so slow pasting 30 characters takes several frames. That's not too annoying, but I might replace it with Wezterm or something.

The stock Windows terminal experience is awful. Windows has improved markedly recently with `winget`, so maybe they'll get around to fixing the speed sometime, too.

int0x29• 7 months ago

Powershell itself can be noticably slow to even start. Waiting a minute or two to hit a prompt is just annoying. Yes this only happens if you run Windows on a spinning disk but it's a shell. It's shouldn't require an SSD to run.

runjake2• 7 months ago

Powershell is slow to start (~1-8 seconds on my PCs, even without a profile.ps1) and it performs pretty poorly in general (eg. processing texts and pipelines) compared to other options -- even Python by a wide margin.

I love Powershell and I wish MSFT would put a concerted effort into optimizing its performance.

chasil2• 7 months ago

There is one company who decides what PowerShell is, and they are not known for stability in many areas.

Just as easily as Aero switched to Metro, syntax in PowerShell will do what they want, despite impacts to your legacy scripting.

The POSIX shell, on the other hand, is a POSIX standard controlled by the Austin group. The classic adaptation is the Debian Dash shell, which is both tiny and fast, and changes are very, very slow.

Dash can be linked with libedit and used as an interactive shell. Everyone should do so, before learning non-standard extensions in Korn, Bash, Zsh, et al.

Shells are a matter of taste to a great extent. These are different envelopes of features, stability, and portability.

UltraSane5• 7 months ago

If you haven't tried PowerShell I strongly recommend you do. It is really well designed and the way objects are piped between commands is brilliant and very powerful. Combined with property filters you can do SQL like queries. The ConvertTo-JSON lets you export the output of any command to JSON which is amazingly useful. As an example you can dump the entire Active Directory (Assuming you have permissions) by

Get-ADObject -Filter * -Properties * | ConvertTo-JSON > ADObjects.json

And you have access to ALL of the .NET library.

haolez2• 7 months ago

Until you have to quote a string that has ampersands in it :)

ZenoArrow4• 7 months ago

You mean like this...

' "Here is an ampersand... &" '

To clarify, in PowerShell there is a difference between text between single quotes (e.g. '$test') and double quotes (e.g. "$test"). Single quote strings are literal strings, so whatever text is contained within them is reproduced as written. Double quote strings are expandable strings, which means that certain text inside the string is evaluated before it is returned. If you have double quotes in a literal string, you'll see double quotes within that string, and the same should be true for ampersands.

jborean93• 6 months ago

& has no special behaviour in strings, backticks and $ on the other hand do. For example "&Some String&" and '&Some String&' are all the literal value `&Some String&`. Backticks and $ are special in double quoted strings as they are the escape character and variable reference chars respectively.

pksebben• 7 months ago

caveat up front: I see that the point here is to talk about a nice, good thing for people to use that is useful, and I don't think that's a bad thing. I am also always looking for ways to upgrade, and I also agree that in a modern context with modern knowledge, we can do better.

However, regarding the posix skepticism - I think OP has missed (or just not mentioned) the actual thing that keeps bash/zsh from being unseated.

Industrial standards are a good thing just because they’re standards. They’re right that a redesign would be superior in terms of raw design, but this is only useful if it’s adopted widely enough so that you don’t have to context switch between two fundamental systems. I spin up a new VM somewhere and it's going to have bash. I use a tool and I expect it to follow a particular convention - having to figure out which I'm reaching for adds an amount of friction that would make most work untenable.

I like zsh but I also want something better. Type safety and robust completions would make me very happy, but if we're going to make the switch we have to do it as an industry - with a set of agreed upon interfaces and standards that are carefully thought out and built on consensus. I don't know if that's possible given the massive complexity of the state of affairs but that's what it would take.

maxloh2• 7 months ago

Nushell commands are really great, so great that they are even better than the standard library of some languages. However, the language itself isn't very intuitive to learn.

I wish Nushell and Python/TypeScript have a baby one day.

Barrin92• 7 months ago

well if you want a python/shell hybrid there's always xonsh (https://xon.sh/). Really great in particular for people like me who are bash-challenged. I do like Nushell too but I also always had problems remembering the actual language.

maxloh2• 7 months ago

I actually meant something like that with Nushell commands. They output structured data that Python and JavaScript can easily leverage in theory.

  C: > ls
  ╭────┬────────────────────────┬─────────┬─────────┬──────────────╮
  │  # │          name          │  type   │  size   │   modified   │
  ├────┼────────────────────────┼─────────┼─────────┼──────────────┤
  │  0 │ Program Files          │ dir     │  8.1 kB │ 2 hours ago  │
  │  1 │ Program Files (x86)    │ dir     │  8.1 kB │ 2 months ago │
  │  2 │ Users                  │ dir     │  4.0 kB │ 4 months ago │
  │  3 │ Windows                │ dir     │ 16.3 kB │ 4 days ago   │
  ╰────┴────────────────────────┴─────────┴─────────┴──────────────╯

bflesch• 7 months ago

I wish Nushell and Python/TypeScript have a baby one day.

That would be nice. Or a TypeScript transpiler to rust ;)

fainpul• 7 months ago

My pet peeve with nushell: broken tables

https://github.com/nushell/nushell/issues/13601

https://github.com/nushell/nushell/issues/16379

wpm4• 7 months ago

for i in 1..10 {

    print $i

}

really all that more readable than

for i in {1..10}; do

    print $i

done

Like, am I taking crazy pills? They're basically exactly the same!

piekvorst3• 7 months ago

Bash is an advanced beast. In Bourne, it was

    for i in `seq 10`
    do
        print $i
    done

Which is pretty much readable though. The only issue is Pascal vs C syntax. As a fan of the former, I admit that the latter is more advanced: it stacks better. E.g. consider

    if (test -f junk) rm junk

against

    if test -f junk; then rm junk; fi

The former “avoids semicolons that Bourne requires in odd places, and the syntax characters better set off the active parts of the command.” [1]

1: Rc—The Plan 9 Shell https://9p.io/sys/doc/rc.html

wpm4• 7 months ago

The semicolon is required only when not using new lines to split the command words, as in

sleep 60; do_the_thing_that_needs_a_minute_wait

It's not necessarily required in the for loop either, I tend to prefer the more compact method of putting the "do" on the same line as the for. It can be written as

for i in {1..10}

    print $1

done

Having "done" be the signifier of the "the for loop context ends here" is 3 characters more than "}" or ")" or whatever else. "done" is more color coming off the screen with syntax-highlighting, and can be typed in two keypresses with a "d" and a "tab" in any editor from the last 30 years. It just seems like a very very inconsequential nitpick. At least Nushell doesn't pull a Python and just have "invisible space" be the end of the for-loop.

One line conditionals are doable as well in the shell.

test -f junk && junk

[[ -f junk ]] && junk

You can even just use [ -f junk ] if double brackets is giving the yuck.

cassepipe2• 7 months ago

I have never seen the second version. Apparently it's there since bash 3.00 (2004). Maybe took inspiration from zsh who also has (or a common ancestor ?)

Qwertious• 7 months ago

The former is easier to remember. You can't forget the semicolon if there isn't a semicolon to forget.

runjake2• 7 months ago

It depends on where you're coming from.

To myself, I agree, but to a Windows native power user, the latter looks confusing.

Source: Windows native colleagues.

wpm4• 7 months ago

Imagine though, if we shell-heads came over to Windows and started writing an entirely new shell to replace Powershell because we didn't want to learn Powershell. It's just so utterly bizarre to me. I guess people like what they like, and that's cool, but wanting to rip out a 40+ year old scripting environment and command line shell because it doesn't look like goddamn Ruby or Clojure or Rust or whatever is just intolerable.

jiehong• 7 months ago

Still not super stable.

Each releases breaks something, usually, and it’s been like that for a few years (like the default config file that was generated is no longer parsed after an upgrade, or a function was renamed, etc.)

I guess they are trying to go this way with their standard lib somehow.

kermatt• 7 months ago

This is the primary problem for me with new shells.

On my workstation I can probably handle (minor) breaking changes, but I need stable runtimes on servers, which is why Bash still is still my default.

Aerbil313• 7 months ago

Do not let the "shell" in the name fool you. Nu is a full on programming language. I've spent more time with it than pretty much any other lang and if I have to describe it in one sentence, I'd say: It's the most beautiful combination of the ease of Python, strictness and ergonomics of Rust and of course shell capabilities of Bash.

It's really its own kind of thing. It's definitely not just another shell.

I've written very impressive and very complex software in nu. I fully expect it to take off very fast as it nears a stable v1.0. I can't imagine going back to anything else.

b00ty4breakfast• 7 months ago

this is very weird timing, I literally just installed nushell this morning lol. I like it so far but that may just be the novelty effect. I gotta find a syntax file for vim, tho, because moving over my bash aliases and trying to visually parse the config file after 10 lines or so is making me go cross-eyed.

sunshine-o• 7 months ago

Nushell is a fantastic project.

Something I came to appreciate is that the 50MB binary is really battery included. You will be able to deal with JSON, XML, SQLite DBs, HTTP requests and more. I personally do not need anything else.

Now, no matter how much you get excited about it, do not write too much production code with it as it still change and break often between releases.

Sunscratch• 7 months ago

I’ve created a small utility script at work that automates some routine tasks and nicely formats the collected data in a table, and I can say that Nushell is an amazing tool.

yencabulator• 7 months ago

Last I looked, Nushell

- error handling is neglected in the basic design: <https://github.com/nushell/nushell/issues/10633>, <https://github.com/nushell/nushell/issues/10856>, <https://github.com/nushell/nushell/issues/8615>, <https://github.com/nushell/nushell/issues/6617>

- control-C interrupts its internals with obviously-wrong error: <https://github.com/nushell/nushell/issues/8828>, is mishandled in other ways <https://github.com/nushell/nushell/issues/8206>

These bugs have existed for so many years I've 100% given up on Nushell. I recommend you don't subject yourself to software that is this level of unreliable and unbothered about being so unreliable.

(There's a lot of missing/misimplemented features, but the above is so severe they're not even worth mentioning.)

joemccall86• 7 months ago

FWIW it looks like this addresses the pipe error behavior: https://github.com/nushell/nushell/pull/16449

xpe7• 6 months ago

Looks like https://github.com/nushell/nushell/pull/13515 fixes https://github.com/nushell/nushell/issues/8206.

xpe7• 6 months ago

These bugs have existed for so many years I've 100% given up on Nushell.

First, at least some of the issues linked have been addressed. Second, they don't strike me as severe. So, all in all, the above take seems like an exaggeration from my POV.

To what degree do these affect the commenter above? Other people? I've not noticed them myself. Maybe there is more to the story?

I recommend you don't subject yourself to software that is this level of unreliable and unbothered about being so unreliable.

Can the above comment say more about "this level of unreliable"?

Think of all the people using Nushell. Out of say N hours of usage of Nushell, what percentage correspond to a user feeling something like "Nushell is unreliable and/or buggy in a way that notably affects me"? Of course I don't have data, but I would guess it would be very small, probably 0.5% or less.

My feels would be that people who "leave" or "bounce off" Nushell mostly do so for other reasons, such as (a) not POSIX compatible; (b) it feels weird to some due to its design decisions (maybe pipelining for example); (c) it has a learning curve because it is different; (d) things change quickly; there are breaking changes. But I would be surprised if there was anything close to ~0.1% of people feeling like Nushell is anywhere in the ballpark of being even one of these three: (i) deeply-flawed; (b) bug-riddled; or (c) led by people unbothered by unreliability.

absoluteunit1• 7 months ago

This is the second time I’m hearing of Nushell.

I wanted to try it the first time I heard about it but completely slipped my mind so this is a good reminder.

hulitu• 7 months ago

The truth is, in 2023 if someone asked us to design a system, we wouldn't design POSIX.

You can design anything you want (see GTK for an example of moving target). But if you want anyone to use it, better stick to standards.

The Case for Nushell (2023)

Related Stories