The Case for Nushell (2023)(sophiajt.com)
sophiajt.com
The Case for Nushell (2023)
https://www.sophiajt.com/case-for-nushell/
72 comments
> 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.
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.
FWIW it looks like this addresses the pipe error behavior: https://github.com/nushell/nushell/pull/16449
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
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
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.
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.
Windows already has a very good shell called PowerShell.
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.
I love Powershell and I wish MSFT would put a concerted effort into optimizing its performance.
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.
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.
Windows terminal and Powershell are 2 distinct programs
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.
> Waiting a minute or two to hit a prompt is just annoying.
I've never experienced startup times anything close to a minute. Is your computer very old?
I've never experienced startup times anything close to a minute. Is your computer very old?
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.
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.
you cannot tell me that you know the difference between `useradd` and `adduser` off the top of your head.
POSIX tools are _not_ discoverable!
POSIX tools are _not_ discoverable!
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.
Get-ADObject -Filter * -Properties * | ConvertTo-JSON > ADObjects.json
And you have access to ALL of the .NET library.
Until you have to quote a string that has ampersands in it :)
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.
' "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.
That works in some cases, not others. I'm not saying that PowerShell is bad, but it certainly isn't a masterpiece of design.
What do you mean it works in some cases, not others? A literal string is a literal string in all cases.
As for it being a "masterpiece of design", it has it's quirks but compared to common Unix shells (aside from Nushell) it's far better. It doesn't need to have a perfect design in order to be a step above the competition.
I hope to continue to see the growth of Nushell, I can see that becoming the best shell one day.
As for it being a "masterpiece of design", it has it's quirks but compared to common Unix shells (aside from Nushell) it's far better. It doesn't need to have a perfect design in order to be a step above the competition.
I hope to continue to see the growth of Nushell, I can see that becoming the best shell one day.
& 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
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...
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.
The "killer app" is that it's easy to string together multiple commands and have them work more reliably than shells that rely on plaintext. In other words, it's something in-between running individual commands and writing full scripts. I've not used Nushell before, but I'm very familiar with PowerShell which is similar, and it's ridiculously easy to manipulate and explore your file system with confidence that you don't have to rely on hacky and hard to read regex and similar suboptimal solutions.
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.
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.
That was my feeling as well. Why learn some not-used-anywhere-else scripting language when we have bash/zsh with battle tested scripts and snippets? Also, nushell will probably break everything that expects a normal bash/zsh/fish.
I’d probably rather use xonsh as I do more complex scripts in Python anyways.
I’d probably rather use xonsh as I do more complex scripts in Python anyways.
That is how I felt with Zsh, even though Zsh scripting is a step up from Bash. But with Nushell there is a huge space of scripts I now prefer to write in it.
I use zsh because of oh-my-zsh. I don't any of the scripting features.
Please take this with a dose of humor (with which it is intended) ... I wonder if part of you prefers to not see Nushell for yourself? This is totally understandable; in the face of too much information, cutting off branches of investigation can be a good coping strategy.
I freely admit this is how I felt about – to talk about a different technology – the Zig language for at least a year. Until one day I spent about an hour trying it out. I am not a "convert", but it yielded useful personalized insight.
Speaking personally for a moment, when I reflect on my higher-level philosophy, it tells me: "If you notice yourself only «generating a list of reasons why NewThing doesn't fit your existing needs», you might be in a cognitive rut. Current needs matter, but so does ongoing capability development. And psychologically one's awareness of tools tends to shape what we perceive as needs.§"
So, it continues, "Instead, do a timebox and try the thing.* Attempt to see it for what it is rather than relative to what you already know! Doing this is really hard, so you'll probably need to seek out techniques to get better at it over time."
* Assuming it doesn't involve drugs, chemicals, or software supply chains of unknown origin.
§ When you only have a hammer...
I freely admit this is how I felt about – to talk about a different technology – the Zig language for at least a year. Until one day I spent about an hour trying it out. I am not a "convert", but it yielded useful personalized insight.
Speaking personally for a moment, when I reflect on my higher-level philosophy, it tells me: "If you notice yourself only «generating a list of reasons why NewThing doesn't fit your existing needs», you might be in a cognitive rut. Current needs matter, but so does ongoing capability development. And psychologically one's awareness of tools tends to shape what we perceive as needs.§"
So, it continues, "Instead, do a timebox and try the thing.* Attempt to see it for what it is rather than relative to what you already know! Doing this is really hard, so you'll probably need to seek out techniques to get better at it over time."
* Assuming it doesn't involve drugs, chemicals, or software supply chains of unknown origin.
§ When you only have a hammer...
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.
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.
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.
Coming from the shell, one of the most annoying things about Python is working with files. In the shell I can read and write to files on the filesystem with basically no friction and no extra infrastructure. Just a "cat" command or a <, >, or >>. The ease at which input and output can just get tossed around in the shell is the biggest thing I end up missing when I graduate up to any "real" language.
I remember when I first learned how to work with files in Python and thought "Damn, y'all live like this?"
I remember when I first learned how to work with files in Python and thought "Damn, y'all live like this?"
Is
for i in 1..10 {
really all that more readable than
for i in {1..10}; do
Like, am I taking crazy pills? They're basically exactly the same!
for i in 1..10 {
print $i
really all that more readable than
for i in {1..10}; do
print $i
Like, am I taking crazy pills? They're basically exactly the same!
Bash is an advanced beast. In Bourne, it was
1: Rc—The Plan 9 Shell https://9p.io/sys/doc/rc.html
for i in `seq 10`
do
print $i
done
if (test -f junk) rm junk
if test -f junk; then rm junk; fi
1: Rc—The Plan 9 Shell https://9p.io/sys/doc/rc.html
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}
do
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
or
[[ -f junk ]] && junk
You can even just use [ -f junk ] if double brackets is giving the yuck.
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}
do
print $1
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
or
[[ -f junk ]] && junk
You can even just use [ -f junk ] if double brackets is giving the yuck.
In practice, the only noticeable difference I have witnessed is
for (f in *.c) if (test -f $f) cc $f
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 ?)
The former is easier to remember. You can't forget the semicolon if there isn't a semicolon to forget.
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.
To myself, I agree, but to a Windows native power user, the latter looks confusing.
Source: Windows native colleagues.
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.
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.
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.
The example FOR loop in BASH is missing a trick to make it easier to read:
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
for i in {1..10}; do
echo $i
done
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
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.
I wish Nushell and Python/TypeScript have a baby one day.
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.
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 │
╰────┴────────────────────────┴─────────┴─────────┴──────────────╯> I wish Nushell and Python/TypeScript have a baby one day.
That would be nice. Or a TypeScript transpiler to rust ;)
That would be nice. Or a TypeScript transpiler to rust ;)
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.
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.
My pet peeve with nushell: broken tables
https://github.com/nushell/nushell/issues/13601
https://github.com/nushell/nushell/issues/16379
https://github.com/nushell/nushell/issues/13601
https://github.com/nushell/nushell/issues/16379
> 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.
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.
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:
* Maybe it is time to rename `sum` to `checksum`!
[1]: https://github.com/nushell/nushell/discussions/17239
[1 2 3] | sum
[1 2 3] | math sum
* Maybe it is time to rename `sum` to `checksum`!
[1]: https://github.com/nushell/nushell/discussions/17239
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.
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.
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.
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.
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
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
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.
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.
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!
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.
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)
[deleted]
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.
I wanted to try it the first time I heard about it but completely slipped my mind so this is a good reminder.
- 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.)