A recent demo of Nushell given a couple of weeks ago:

https://media.handmade-seattle.com/nushell/

Oh wow...finally someone is bringing the great ideas of Powershell to unix. Can't wait to see how this turns out.

> great ideas of Powershell to unix

Now-If-They-Could-Improve the Syntax To-Make-It-Usable.

At least it's consistent. Verb-Noun

You can run PowerShell on Unix already, but imo it is too slow for interactive use. Getting it to act like a Fish makes it very, very slow

But I think it's quite good for scripting. You can call any system command as easily as in bash while being able to use variables for not just strings. I'd never use it as interactive shell, of course :]

Also... the script will then run only on my machine as most Linux systems don't have powershell and most Windows don't have the Unix commands I still use all the time.

Yeah, I agree that PowerShell is great for scripting. I don't do that much scripting on my personal Linux systems that really calls for PowerShell, but I like using PowerShell for hitting HTTP APIs or processing structured data at work.

> Also... the script will then run only on my machine as most Linux systems don't have powershell and most Windows don't have the Unix commands I still use all the time.

Hahahaha! Oof.

It's more work, but when I use PowerShell, I try to use pure PowerShell, both for aesthetic reasons (cleanliness, ‘portability’) and just in order to practice and learn more PowerShell APIs along the way.

I can't imagine it being any slower then it already is out of the box.

zsh has this absolutely ridiculous case of feature shyness. It has tons of great features, which it goes to great lengths to hide from you for some indecipherable reason.

The reason is to preserve compatibility for everyone's configuration that they carefully built up over decades. It's quite hard to change things to enable some new thing without annoying many users. The last time that was tried was in the '90s and there are still zsh developers around who experienced the fallout. I value the fact that my shell doesn't change on me without warning like many GUI desktop environments.

In recent years the existence of frameworks like oh-my-zsh has contributed further to this situation because it has separated the detailed configuration from the base zsh project. It's a pity omz doesn't enable more really. Many things it does are not really useful unless you take the time to actually learn them. A lot of plugins just define aliases but if you don't know what they are, they just sit there unused.

Well, yeah, this is the problem. Throw new users under the bus in favour of old users.

I'm usually happy to put some effort into configuration upfront as a new user if it buys me the peace of mind that I won't be thrown under the bus later. OTOH, I recall some classmates being unaware that Vim supports syntax highlighting because the version that was installed on our lab computers didn't enable it by default (this was about five years ago), which also seems like a regrettable outcome.

Many of the features are also achievable with pure bash with ble.sh (https://github.com/akinomyoga/ble.sh).

Ble.sh seems pretty cool. The path hacking it does on readlink doesn't work right and causes the CNF handler to launch on NixOS.

I guess it does the PATH hacking based on whether the system is GNU or not so that it can get `realpath`/`readlink -f`-like behavior even on systems that don't natively have that because they include *BSD coreutils.

That might not behave as expected (and is unnecessary) on my macOS systems, either, since I like to keep GNU coreutils (with no `g` prefixes on the executable names) on my PATH there (heresy, I know).

It's also noticeably slower, to the point that there's a bit of jitter as I type.

It's pretty cool, though. If it's any better after I patch the readlink PATH hacking out, maybe I'll configure it for bash on my systems.

I find it amusing when people are discussing all these new shells and features, yet everytime I see someone letting them know they can do these exact same things in bash, there's absolute silence. It's not the first time I see ble.sh being recommended here with no reactions from the community whatsoever. As for fish, I've used it for a few weeks. Not having POSIX compatibility and GNU readline shortcuts made work much, much harder.

> Not having [...] GNU readline shortcuts made work much, much harder.

That's weird. Fish has all of the GNU readline shortcuts OOTB and has for as long as I can remember

Zsh has become an indispensable power tool for me. I am interested in other shells (especially PowerShell), but Zsh is now embedded deep in my brain, next to Vim and Python, and I doubt I will ever seriously migrate away.

That said: what do you like about Nu shell specifically?

> what do you like about Nu shell specifically?

A whole bunch of things:

1. abandonment of POSIX shell syntax. We can do better. I'm happy with Zsh being POSIX-compatible, and that will always be there.

2. a focus on structured data. Nu basically has hierarchical dataframes built-in, along with lots of facilities for their manipulation. There have been a few other attempts at this but the benefits are obvious. Rather than figuring out how to `awk` your way through whatever text output a command generates, command output in Nu is structured and everything can be handled in orthogonal ways.

3. modern conveniences built-in, like syntax highlighting, and AFAIK they want to include features like "do something when you cd into a directory" that we currently need more tools for (i.e. direnv, which I highly recommend!)

4. serious technology. The people behind it are experts and JT has been showing off (https://youtu.be/3o8b_QcrFHc) the engine that enables trivially parallelizable loops. No more need for `xargs`.

5. I hesitate to mention "made in Rust" as a feature, but using a modern language for core infrastructure does matter.

I'll put it this way: Nu shell seems perfectly supportive of my philosophy that a shell is basically a REPL for a computer, and they're taking the ergonomics of an interactive REPL along with the programming language that powers that REPL seriously.

The thing is, there's currently NOTHING GOOD for "shell scripting". Shell sucks (yes it does), so for anything more than very short things I'd rather write Python. But Python sucks for shell-like things, parallelization, it has slow startup, and you also can't do things like put environment variables into your session or change the working directory, so you often wind up writing shims (eg. Broot's br alias - https://dystroy.org/broot/install-br/).

Yes I've looked at Xonsh but maybe the additional syntax is offputting to me. Like, I wouldn't use it as a shell over Zsh (how's Xonsh's fzf support? I don't know, but I know everything's going to support Zsh), and I dunno if I want to use its syntax extensions over just Python. Though It's always on my list of things to re-explore, and maybe it'll click one day. But it being based in Python makes it feel slow (I wrote my prompt in Zig to get it to be fast...)

This is relevant to mention: I wrote a small Python library (https://github.com/kbd/aush) that's basically a DSL for subprocesses, so it tries to make it more convenient to do shell-like things. I find it preferable to shell or Python alone most of the time. Here's an example of its use in my script that creates a new Python project: https://github.com/kbd/setup/blob/master/HOME/bin/create-pyt...

I haven't figured out a convenient way to implement shell piping well with Python's pipe operator, or pass through interactive output directly (so things that "update" the display, like poetry and npm don't behave the same as they do interactively) so it's still .9 status, but it works really well for what it is, and you can always write "regular Python" along with it.

Anyway, Nu seems to be an attempt to put a "real" programming language REPL in my shell, from people who have serious language experience, so I'm hopeful it'll be great.

> A whole bunch of things:

I appreciate the clarity of your message... curiously enough all the things that you mention I see them as anti-features of nushell (except the first one)

1. Posix shell is clunky has its limitations but there's nothing really flawed about it. It is nice to have non-posix shells, though; in that I agree with you.

2. I hate hate hate the very concept of dataframes. They seem like a useless over-engineering. Plain tabular data is a perfect, and the columns of a table are always named 1, 2, 3. The whole point of abstraction is that you do not care about the meaning of the columns of your table, and the programs (like the lovely awk) that deal with these columns do not care either. There's nothing more "orthogonal" than that: filters that do not understand the data but can filter it anyway.

3. syntax highlighting is a very personal issue; in my case I prefer my terminal not to look like a christmas tree.

4. xargs is one of my favorite tools (alongside gnu make and gnu parallel) and there's nothing "unserious" about it. The happiest moments in my programming life are when I get to use these tools. Not using xargs sounds like a nightmare!

5. Rust is definitely an anti-feature to me: it's like a language that was built by picking the worst features of many already ugly languages. I would not really care in what language the shell is written, but I'd rather have it written in saner, "unsafe" languages.

> Posix shell is clunky has its limitations but there's nothing really flawed about it.

I think shellcheck is the best argument against this. POSIX shell is just stuffed to the brim with weird gotchas, places where the obvious way to write something causes subtle bugs down the line.

It's the only programming language I use that feels adversarial, where you have to be paranoid to properly solve simple tasks. (Admittedly some of that is because of the reliance on system programs rather than the shell language itself.)

> It's the only programming language I use that feels adversarial

This may be just that you are not very used to the language. I have the same dreadful feeling (that the language fights against me), even when using languages that I'm reasonably proficient with.

For example, in C++, a simple expression like "y = f(x);" already gives me the chills... Is the () operator overloaded? and the assignement operator? If the object x has size equal to 10GB, and y is supposed to have the same size, how much memory does this operation require? 10GB? 20GB? 30GB? 40GB? each of these completely different answers is perfectly reasonable, depending on extremely delicate details of the implementation.

Garbage-collected languages are even worse, I never know whether they will start a memory reclaiming spree that will halt my program for a few seconds.

Even in python, I have this sort of jump scares a few times per month.

I strongly disagree about data frames. I am a data scientist professionally, and I think the data frame is one of the most important programming abstractions I use.

Thanks for that, fzf-tab was the last missing piece in my setup.

Nice. Yeah it works great. I have an extensive set of git aliases. Yesterday I was merging a branch with `gmn` (`git merge --no-ff`, which is actually an alias to `g mn`, where `g` is an alias to git of course) and it gave me a fuzzy find of my branches through all the aliases.

Edit: also things like `kill`. `kill [tab]` gives you a fuzzy-find list of all your processes so it's way faster to use than ps | grep.

> while Fish has some nice out-of-the-box features, they’re all achievable in Zsh with a few lines of plugins.

The point of fish is that there is no configuration required.

You don't have to learn to configure it, you don't have to be part of "the community" to learn which plugins to use, you'll be able to sit in front of any fish prompt and have it work as expected without having to move dotfiles around.

That's a cool argument for Fish for beginners. When you spend thousands of hours in a shell that doesn't matter as much. I don't see any benefit for someone who has Zsh set up well, but yes you do have to google once how to configure auto-completion and so on.

Probably little for anyone who has any shell “set up well”. Just if they are tired of spending time tweaking things and would rather more capable out of the box experiences so they can benefit from features added to the core shell without hunting for plugins.

I use Fish, however I also use Vim and do the plugin hunt there. I enjoy it, but I’m glad to not be doing it for both my environments.

Comparing the "plugin hunt" between vim and zsh is a bit much. I use three for Zsh, just syntax highlighting, autosuggestions, and fzf-tab. I don't use a Zsh plugin manager.

> The point of fish is that there is no configuration required.

I think it would be more accurate to say that the point of fish is that there is no configuration allowed. If you don't like the out of the box configuration, I would say configuration is still required, but it's unfortunately not available. If you happen to like every single decision the developers made, then I admit having no configuration does mean you end up with a simpler, faster, more maintainable shell.

> If you don't like the out of the box configuration,

Then either decide to like it -- humans are adaptable, this is possible -- or don't use the thing. Both outcomes are acceptable. A hammer doesn't need to have a configurable grip and head and claw in order to be a good tool.

Yes - that's exactly what I said. I'm not sure where you think you disagree. The point of fish is that configuration isn't allowed. I, personally, don't use it.

I guess there isn't disagreement! :) Maybe the point is that you would say it's not allowed whereas I would say it's not necessary.

Fish isn't that extreme. There's a fair bit of configuration allowed. The devs are just judicious about adding toggles.

You can configure scripting to run at various times, and there are even plugin frameworks for Fish. It just doesn't have toggles for things like language features in the way that ZSH does.

I think this really shows the two schools of thought, and this is reflected in the attitude towards linux too.

A: Linux is amazing, I can configure everything the exact way I want.

B: Linux sucks, I need to mess around with configurations for hours before I get something usable.

A lot of us just want something that works out of the box with amazing defaults. Others want something that can be tuned to their exact preferences. However, configurability comes with it's own costs too.