GitHub – nushell/nushell: A new type of shell | Hacker News Reader

GitHub – nushell/nushell: A new type of shell

github.com

763 pointsaxiomdata316398 comments

Thinking this is so cool! I was wondering if seriously buying into an alternate shell like this would be worth it in the long run.

Would really love to read from people who use(d) an alternative shell, both success and failure stories.

I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work because you'd then be introducing an implicit dependency on your special snowflake non-standard runtime. Which is something we came to accept and assume for interpreted languages (Python, Ruby, Node, etc.) but I'm not yet ready to assume for shell scripts.

So right when I was going to test Nushell, I discover there are also other shells like Elvish [0] and Oil which supports structured data [1]. Now on top of my hesitations I'm adding decision paralysis :-]

[0]: https://elv.sh/

[1]: https://www.oilshell.org/

Lots more shells: https://github.com/oilshell/oil/wiki/Alternative-Shells

I wouldn’t use a custom shell in company work, but I’d use it for company work. I treat custom shells like a custom keyboard or shortcuts in the OS. Shells can help a lot in your day to day command line ergonomics, like presentation (always know which branch and directory I’m on, time and time taken for commands) and ease of use (autocomplete, aliases, shortcuts). But I wouldn’t script into them for professional work. Just plain bash in that case. We really don’t want devs fighting over which shell to install on the servers, but everyone can go crazy on their own laptops.

I agree... and any well written script will have a shebang that specifies the shell that shluld run it, anyway.

For me, personally, I love having homogeneus systems put in place. In this case it means not having to switch my mind between in and for modes. Helps me avoid mistakes, having to keep less context up here. But it's always interesting to read about other people's way of working.

If you want to make the systems homogeneous, then you need homogeneous teams, too. Maybe some team members prefer fish, others prefer zsh, still others prefer bash. Your suggestion means that everyone has to use the same shell for their command line.

I find that it is better to allow each team member to have their own working environment: different (command line) shell, different editors/IDEs, different keyboard shortcuts. But everyone uses the same programming languages (counting shell as a programming language for scripts here) and the same build tools and the same linters.

no no no, I meant that I prefer using Bash everywhere, including my own machine, because anyway I'll need to end up translating most stuff I write to a Bash or even POSIX compatible script so... as someone said in other comment, why not cut the intermediary step. It makes it easier for me, the less context switches the better production code I'll produce.

But of course, I believe others should be free to make their own choices! As long as their choices don't end up affecting the quality of the code that ends up shared with the rest of the team...

Which brings an interesting point: I don't have a problem at all with you using whatever shell you want. But I do have a problem if because you don't use Bash in your day to day, you are less used to its ins and outs, you don't put in the extra work that is being as proficient with Bash than you are with your personal shell, and your scripts end up with bugs in how Bash arrays are treated (just a quickly made up example)

Yup. There are more shells than there are IDEs, keyboard switch types, keyboard layouts, and operating systems. Shell ideological wars get just as bad as emacs/vim and linux/Mac. Use whatever you want, but company IP is shbang'd to bash.

I'm generally supportive of the effort to replace the archaic shells that dominate the unix landscape, but unfortunately none have yet met my personal desires.

It seems like a lot of the developers of these shells create them to supplement the common unix toolset, but I really want a complete replacement. Ideally, the shell itself would be a completely dependency-free static executable, with a built-in command set that includes functions to interface with all the kernel's user space accessible features, acts as a repl, with sensibly named commands, and a simple method for interfacing to and from any other program. In short, I guess I'm looking for something to act as the basis of a completely new environment on top of Linux. As it is, most of these do not even meet the first of the criteria.

FWIW, nushell is much more of this than it appears. While many commands share names with Unix commands, that is the only similarity for quite a few, since they are rewritten to return structured data instead of text.

From what I recall about nushell, it only scores 2/5 of my criteria.

Right, it’s still very early and something needing to be contributed to. However I have spoken to the creator (regretfully I haven’t had as much time to contribute as I would’ve liked); he is very open to improvements and the direction of the project is pretty open.

So I take it you're waiting for the systemd shell then? lol

I tried fish for a while. The differing syntax between fish and bash for fundamental things mean I was running all my scripts through bash anyway, and if I wanted to share them/use them elsewhere in the company it had to be bash, so I swapped back to bash.

If you're running scripts, what difference does it make that you use fish? You're not really supposed to write scripts for fish, unless it is meant to be used be the fish shell itself. A shebang on the top of your script will invoke the script with the right executable, and whether you called it from bash, zsh or fish would make no difference.

So, instead of just typing shell commands, you type something else, but as soon as you need a shell script, you have to go back to shell commands.... Why not just cut out the middleman?

Answer to the first question: yes. Answer to the second question: because bash is a rather poor terminal shell.

In my experience, the middleman you mention doesn't exist. Or, if anything, it is a very tiny man that hardly gets in the way. It's either a one-liner with a syntax change you can pick up in 5 minutes, or it falls under any combination of these:

- might as well belong in a script

- the complicated stuff is in awk or the likes

- you can just enter bash for any copy-pasted bashisms

- you can execute it explicitly with bash -c

In any case, none enough of a hassle that it could demerit the immense productivity benefit I've gotten from fish. The only regret I have on that matter is not having ditched it sooner. Use bash to run scripts, or even better, sh. Use a different shell to make your life on the terminal better. Doesn't need to be fish, zsh is pretty good too.

If I can offer any advice: if you still want to stick with bash, at the very least take a look at fzf, https://github.com/junegunn/fzf , aside from fish/zsh it's the best and most lowest hanging fruit.

> You're not really supposed to write scripts for fish

Given that 95% of my time in a shell is running a script, a shell that doesn't do that well isn't a great fit for me.

> A shebang on the top of your script will invoke the script with the right executable,

Assuming the person who wrote it had the foresight to do so. That person isn't always me, and if I have to manually check if each script I run has a shebang, I should just default to running them in bash.

I haven’t seen a shell script in ages that was missing the shebang. Is this common in some places?

I’ve started to write dash scripts because that seems to be reasonably posix and bash on macOS is ancient.

I would consider a person who doesn't use a shebang to be bad at their jobs.

Even the most basic of tutorials will include it even if it means nothing to the user.

That's not entirely weird to me.

For the longest time bash was in various states of disrepair on different Unixes. I could make it segfault pretty easily.

I wrote scripts that had to run across Linux, BSD, HP-UX, Solaris, and AIX at the time. So we relied on a ksh88 implementation on each. Whether it was AT&T, mksh, or pdksh, it was fine. Couldn't rely on 93isms, but basically anything POSIX was cool.

I used ksh93 interactively for the longest time. But then Linuxes stopped testing interactive use w/ their packages and it became unusable (looking at you RedHat). So I used bash interactively but still wrote those ksh scripts.

These days, I use zsh locally on MacOS and BSD, but mostly write bash scripts for those and Linux. I still stick to the POSIX habits I have for portability. But the variances are so less. The only one that annoys me is the "does sed -i do in-place" game.

I don't think my interactive shell and target scripting shell have ever matched 1:1 in feature set. And what I slap together interactively or for 1-off script, I would never do for a "real" script. And that's a thing that bugs me with a lot of shell scripts I see in the wild.

A "real" script should make very little assumptions, fail safely, be low on resource utilization to not risk impacting a business workload, and be maintainable. I write everything real like it might be run thousands of times accross thousands of hosts. Even when I didn't intend for it to be, I've caught it in the wild because someone borrowed what I did.

I do love shellcheck, because it teaches our newer folks good habits and they're used to that kind of feedback in other languages. It catches so many things that make me cringe. It's not perfect, of course, but pretty great.

When I started out, I worked 9-6 and the Unix sages in my group worked later hours. So they'd walk through my work on the RCS host and I'd come into the morning with a critique in my email. If I didn't understand, I could hit their desk after lunch and they would patiently explain to me. I love them for it, but it is nice to have tools without a 24-hour feedback loop.

Shellcheck is nowadays a must for writing decent shell scripts. it is like a centralized knowledge base of all those brilliant minds that did the sanity checking for you in the old days :)

It boggles my mind that people use a language where

x = 0 doesn't work and x=$y is a security flaw

I used fishshell for years, and the bottom line ended up being that it created enough mental overhead to be a burden because it diverged from the UNIX norm too much. Sort of like the colemak keyboard layout, sounds great in theory, in practice, not so much.

Fish user here. I've accepted having to drop down to bash here and there. No big deal for me.

I tried fish for a short while too and quickly realized everything depends on bash/dash. I then switched to zsh which is mostly compatible. I installed Oh My Zsh and a fish-inspired theme with line autocompletion and coloring and never looked back. But I still use zsh for the interactive prompt only, still writiiing #!/bin/sh scripts for maximum compatibility between platforms.

I went through the same thing.

It also got on my nerves that scripts which did not identify themselves correctly as bash would run in [ whatever hot new shell im running ], often with bizarre results.

I don't know if fish counts as an alternative shell since it is still pretty close to bash and zsh, just with better defaults requiring less configuration (similar to i3wm with respect to "better defaults").

I just use it as interactive shell and for scripts I use `/bin/sh`. So I don't really run into a lot of problems, only sometimes with scripts that do not have a proper `#!/path/to/shell` declaration at the top.

("better defaults" is of course entirely subjective but for fish, i3 and Doom Emacs they mostly align with my preferences)

I’ve been poking around with Sway, coming from Gnome (which I mostly love). What got you into i3 vs a normal desktop, and how long did it take you to realize it was a good fit?

Phew, I've been using tiling window managers for 15+ years now so I don't really know. I've always been interested in trying out different window managers and UI/UX concepts.

When I started with Linux in the 90's it had FVWM by default as graphical interface which was pretty different when being used to Amiga, Atari ST and Windows 3.1. (They were all pretty different from each other.)

Of course I had to run Enlightenment with some rusty graphics when I discovered it, but I think WM2/WMX[1] was the first window manager where I realized I preferred the more minimalistic ones.

After trying out more WMs I ended up at awesome[2] which I ran for years. It had the best support for both floating and tiling windows. (I do like some floating windows now and then but never liked the "normal" desktop concept which is, paraphrasing Fred Brooks, more of a flight seat concept.)

Then WMs like xmonad started appearing and I tried those out but they're pretty much "tiling only" and I did not like xmonad's tiling windows approach. It's been too long since I used it and I'm not sure it is still applicable but it forced you to use specific layouts and the current window was always maximized.

So at some point i3 appeared (like fish shell and Doom Emacs) and when trying it out it by default already did most of the things that I liked and that I had to configure in other window managers, so that was nice. It was a pretty good fit right away.

I have used some other WMs like EXWM and StumpWM over the years because I'm both an Emacs and Lisp weeny but they're like less mature i3 clones so I've been back at i3 for a while now.

[1] http://www.xwinman.org/wm2.php

[2] https://awesomewm.org/

I've been using Xonsh[0] for a couple years as my daily driver and I swear by it. I'm also a Python dev so that's part of the appeal. It's billed as the "unholy union" of Bash and Python.

[0] https://xon.sh

Xonsh is also my daily driver for years and years. Combined with direnv I have really not missed much of anything from other shells. So much stuff either works out of the box or has some little hacky wrapper to handle it.

Yup. I'm a huge fan of the vox plugin approach to python and venv management. No more virtualenv hacking the shell... it's a first-class citizen. Plays nice with pyenv too

This sounds nice enough that I'm considering installing xonsh just for python development

use it as an interactive shell first, not for shell scripts.

also, why would any dependency of your projects at work be implicit? all dependencies should be captured somehow, the very least in some documentation.

at our company, we use shell.nix files to declare all of our dependencies, so everyone has the exact same software available on their development workstations.

it's not a completely trivial thing to do, but worth investing into it, to lower the chance of surprises, which will happen when you can afford them the least...

here is an example to get started:

``` with import (builtins.fetchTarball { name = "nixos-unstable-on-2021-05-16"; url = "https://releases.nixos.org/nixos/unstable/nixos-21.05pre2893... sha256 = "1kilrk0ipvldf4rrn6aq6v2bj2jfhbz33cjb9w9ngqmbmr2f94wd"; }) { };

let project-jdk = jdk11; clojure = callPackage ./deps/clojure { jdk11 = project-jdk; };

in mkShell rec { buildInputs = [ coreutils cacert direnv nixfmt curl jwt-cli fd python3 nodejs (yarn.override { nodejs = nodejs; }) project-jdk clojure yaml2json

    modd
    devd
    overmind
  ];

  shellHook = ''
    export LC_CTYPE="UTF-8" # so tar and rlwrap won't complain
  '';

} ```

it shows how u would use your custom package (for clojure in our case) and how would u pin there state of the whole package repository to a specific point in time.

in the past I've used es, the extensible shell (https://wryun.github.io/es-shell/), this way, without bothering my colleagues with teaching them about it. they just git pull, press enter in a shell within the hour repo and direnv will pull down any new dependencies.

> also, why would any dependency of your projects at work be implicit? all dependencies should be captured somehow, the very least in some documentation. .... Nix.

Because distributing software is hard, especially if things change. That's one big reason why Docker images will sometimes get used for development environments (like what VSCode supports).

Nix is nice, and is a pretty good way of capturing those dependencies. But it's also difficult to customise, often lacking in documentation, and not used very widely.

If you're not using something like Nix (i.e. most people), it's natural for dependencies to be quite implicit.

I understand that the industry largely does not acknowledge how big of a problem implicit dependencies are, but since the OP is clearly aware of some issues with implicit dependencies, I was just surprised why so content with these issues. It clearly hinders the adoption of upcoming technologies at least in the mind of the OP.

I'm not really an expert in the Nix expression language. Hasn't even finished reading the Nix pills, which is a very practical documentation, yet I could manage to extract a lot of benefit from that shell.nix template I've shared. I'm using Nix for 3+ years now. Because of this experience I do encourage others not to be afraid trying Nix. It gets better with every release.

Docker is a halfway solution and because of its memory and storage requirements it often strains the average development workstations and internet connections.

Perhaps someone already mentioned this elsewhere, but nothing forces you to use only a single shell. A shell, after all, is just a running process. Yoh can even launch it from another shell.

As a GNU screen user already, I can imaginr having one of my default windows that load when I launch screen be nushell if I was so inclined. I can keep the rest as my default (e.g., bash or htop or whatever else I wany running there).

There is something very important that forces me to use a single shell: Habit.

I tried and returned to Bash. There is something about using defaults.

> I cannot shake from my head the idea that buying into a non-standard shell will only work for personal projects in one's own workstation, but it won't fly too far for company work because you'd then be introducing an implicit dependency on your special snowflake non-standard runtime. Which is something we came to accept and assume for interpreted languages (Python, Ruby, Node, etc.) but I'm not yet ready to assume for shell scripts.

Is it so bad? I run arch at home, I would never do that for a production server. I use rust at home, but it's unlikely to get introduced at my work any time soon. I use elm for solo projects, and I've never once convinced my managers to even try it (and believe me, I tried).

Context switching is pretty normal, I wouldn't let that get in the way of trying something new and interesting. Personally I find elv.sh the sanest scripting language I've tried so far, and I wouldn't trade it back in for bash, even if I'm still forced to use it at work.

A case for trying Elvish:

I really like Elvish's emphasis on interactivity, its somewhat maximalist approach to interactivity-oriented builtins (like fuzzy filtering, its directory browser, etc.), and the fact that it's distributed as a single static executable.

I also like the developers, who are smart and kind people and generally pretty pleasant to interact with on GitHub or their Telegram chat (bridged to various other things).

None of this is a case against trying Oil, however, so perhaps it will not help your paralysis too much. ;)

NGS' readme also has a good comparison section listing alternative shells: https://github.com/ngs-lang/ngs#have-you-heard-of-project-x-...

You might be interested in chubots comments as he regularly responds to questions related to oilshell:

https://news.ycombinator.com/threads?id=chubot

> Which is something we came to accept and assume for interpreted languages (Python, Ruby, Node, etc.)

Tangential, but:

- "Node" isn't a language, it's a JS runtime

- There's no such thing as an "interpreted language", whether something is interpreted or not is a property of the execution environment, not of the language itself

- The commonly-used runtimes for JS at least are JIT compilers, not "interpreters", and this can be true for some Python/Ruby runtimes too

I didn't downvote your comment. But I guess some people did, possibly because you did the thing about stating several facts where all were true but none were relevant. I'd swear I read that this phenomenon even has a proper name but cannot recall it right now.

(And for the record I know very well about the internals and technicalities about the words and names that I used: Node.js is the de-facto Javascript runtime for the backend, popular to the point that people commonly refer to it as "programming in Node"; Python and Ruby are just languages but their majority of users run their program with the default official interpreter, so through a metonymy we can refer to either even when actually talking of the other; and etc. For economy of the language and avoiding the pedantry, I grounded my comment on the most generally perceived notion about those technologies. You see, just to avoid unnecessarily long explanations like this one)

I use the fish shell and have for several years now.

A few years back I did a startup with a friend -- a cross platform mobile product but with a mess of complex open-source c++ dependencies (which we forked and customized often) -- and we made the decision as we hired developers to over-specify some aspects of the machine environment to make it as easy as possible to share our development workflows. Note that "development workflow" is much more than just "i can run the app in docker" -- but rightfully includes -- I can efficiently run things in debugger, I can run the performance profiling tools in realistic ways, I can quickly execute and test a change someone else is trying to make, I can quickly share a change I'm making with someone else and be confident they can make realistic observations about it, i can setup a fast repro loop for some specific bug or feature ... etc.

We did a pretty good job of getting the know now needed for all those workflows distributed across the team reliably with low effort despite some complicated and weird build system requirements associated with our dependencies.

One of the big bang for buck tricks that helped more than I would've expected was to mandate that everyone had to use fish shell. This really reduces the number of weird effects from random things that people copy/paste into their bash initialization -- with the developer never imagining the strange knock off effects that will one day cause a tool they don't understand to behave in a flaky way for a reason they will never figure out ...

The amount of terrible things that developers randomly accumulate in their bash initialization probably can't be underestimated ... there's probably more risk of "weird problems" associated with advice on stack overflow related to bash initialization than maybe any other topic ...

So I personally think standardizing a team or startup on an alt shell can be a potentially good idea ...

As another point of evidence -- I later headed devops at another startup that took opposite perspective -- "use your own machine and your machine can be configured however you want and you just have to figure out dev workflows on your own" and it was extremely difficult to share knowledge about how to accomplish a lot of these basic workflows ... doing anything beyond the most basic ways of interacting with the codebase often involved a rather large amount of hands on dev machine troubleshooting (can you send me your .bashrc and .profile and .bash_profile? ok type these commands ... ok now you can grab my branch and try this to have a look at the thing i'm trying to change ...)

fish is reliable and stable though -- I'm not sure about using a shell that's not been around for awhile in this way ... but I'd support it I think if I already had personal experience that the shell was "reliable enough" ...

The title is somewhat misleading and makes it seem like this is a GitHub company initiative rather than a project just hosted on GitHub.

I've not seen this title format on HN before. Could it be changed?

I think the "nushell/nushell" part makes it clear which repo it is talking about.

I didn't find it clear, I also thought it was a GitHub project.

I found it clear it wasn't a GitHub project.

The point of a title is to be obvious to everyone (to the extent possible) -- the fact that we found it obvious doesn't remove their confusion.

It wasn't clear to me that any of the interpretations was, well… clear, and had to check the comments (I could have checked the repo too).

Really seemed like a GH project to me.

Yeah i thought it was like "Github - Atom Editor"....

That's on GitHub in fairness. Left is logged in.

https://cdn.imgy.org/DOyx.png

I think just "nushell/nushell: A new type of shell" would be a clearer title.

I'm in that camp. I read the URL without issues

no.. I didn't find it clear..

The title is the actual value of the title html tag on the page

Heh, that's interesting: When you're logged in, the title tag changes to drop the "GitHub -" prefix.

SEO strikes again!

Considering people often search 'github project name' it probably makes sense.

It could go at the end just as easily like every other site though

I can see the confusion but it didn't confuse me. If it's a GitHub product it would only be a blog post I would expect not actual code ironically.

Same, I thought it was a GitHub project. There are often links to GitHub pages on HN and I don't think they generally have the "GitHub" prefix. It's not relevant anyway where the code is hosted.

I think it is very likely "disagreement" in this thread is simply based on people seeing different titles at different times. There are some possible causes:

1. The submitter may provide an initial title

2. HN moderators may adjust the title

3. GitHub may show different titles based on the user's login status (I'm not sure myself, I'm writing this based on what I read in another part of this thread)

Therefore, I make this request of HN commenters: Since titles on HN can change, please quote the exact title that confuses you.

More broadly, it may be useful to always quote the text you are responding to.

Right. It doesn't seem important where the project is hosted.

I got excited thinking it was an official Github project.

same here. I thought it is GitHub project

Not only is the place the project is hosted totally irrelevant to discussion, it seems like it would make more sense for this post to link the project website (www.nushell.sh/) instead of the GitHub repo.

dang will most certainly change this title when he spots it. I have been tracking HN title changes and they follow a very predictable format. Here are some recent results,

      Universities have formed a company that looks a lot like a patent troll
  was Universities Have Formed a Company That Looks a Lot Like a Patent Troll
  
      Linux with “memory folios”: a 7% performance boost when compiling the kernel
  was Linux with “memory folios”: got a 7% performance boost when compiling the kernel
  
      Strategic Scala Style: Principle of Least Power (2016)
  was Strategic Scala Style: Principle of Least Power (2014)
  
      The rise of E Ink Tablets and Note Takers: reMarkable 2 vs Onyx Boox Note Air
  was The Quiet Rise of E Ink Tablets – ReMarkable 2 vs. Onyx Boox Note Air
  
      Big tech face EU blow in national data watchdogs ruling
  was EU court backs national data watchdog powers in blow to Facebook, big tech
  
      Emacs Love Tale by sdp
  was Emacs Love Tale by Sdp
  
      Future from a16z
  was Andreessen Horowitz goes into publishing with Future
  
      Richard Feynman’s Integral Trick (2018)
  was Richard Feynman’s Integral Trick
  
      The Tinkerings of Robert Noyce (1983)
  was The Tinkerings of Robert Noyce
  
      NIH study offers new evidence of early SARS-CoV-2 infections in U.S.
  was NIH Study Offers New Evidence of Early SARS-CoV-2 Infections in U.S.
  
      Time to sunburn
  was It's surprisingly easy to get a sunburn
  
      The home computer as a cultural object is physically vanishing (2007)
  was The home computer as a cultural object is physically vanishing
  
      Mackenzie Scott gives away another £2B
  was Billionaire Mackenzie Scott gives away another £2bn
  
      A pilot program to include spirituality in mental health care
  was Psychiatry Needs to Get Right with God
  
      What we learned doing Fast Grants
  was What We Learned Doing Fast Grants
  
      Joplin – an open source note taking and to-do application with synchronisation
  was An open source note taking and to-do with synchronisation capabilities
  
      Show HN: Influence, a Go-inspired 1-minute board game
  was Show HN: Influence, a Go-inspired 1min board game
  
      J Concepts in SuperCollider
  was J Concepts in SC (SuperCollider)
  
      Joplin – an open source note taking and to-do application with synchronization
  was Joplin – an open source note taking and to-do application with synchronisation
  was An open source note taking and to-do with synchronisation capabilities
  
      Forzak: A website that curates high-quality educational content
  was Forzak: A website that curates high-quality educational content on the Internet
  
      DraftKings: a $21B SPAC betting it can hide its black market operations
  was DraftKings: A $21B SPAC Betting It Can Hide Its Black Market Operations
  
      We’re no longer naming suspects in minor crime stories
  was Why we’re no longer naming suspects in minor crime stories
  
      Operation Midnight Climax: How the CIA Dosed S.F. Citizens with LSD (2012)
  was Operation Midnight Climax: How the CIA Dosed S.F. Citizens with LSD
  
      Modelplace: AI Model Marketplace by OpenCV
  was Modelplace, the AI Model Marketplace by OpenCV
  
      Don't just shorten your URL, make it suspicious and frightening (2010)
  was Don't just shorten your URL, make it suspicious and frightening
  
      Kuhn's Structure of Scientific Revolutions – outline (2013)
  was The Structure of Scientific Revolutions
  
      How Indian Zoroastrians helped shape modern Iran
  was An Indian Religious Minority Shaped Modern Iran
  
      RFC for 700 HTTP Status Codes (2018)
  was RFC for 700 HTTP Status Codes
  
      RFC for 700 HTTP Status Codes (2012)
  was RFC for 700 HTTP Status Codes (2018)
  was RFC for 700 HTTP Status Codes
  
      How to Be a Stoic (2016)
  was How to Be a Stoic
  
      Researchers fear a scenario in which smart speakers feed sleepers subliminal ads
  was Are advertisers coming for your dreams?
  
      Google Messages end-to-end encryption is now out of beta
  was Google Messages end-to-end encryption no longer in beta
  
      Stabel: A pure concatinative programming language, now with modules
  was Stabel v0.2.0-alpha: A pure concatinative programming language, now with modules
  
      Recording of the week: A Yanomami ceremonial dialogue
  was Recording of the week: A Yanomami ceremonial dialogue
  
      Stabel: A pure, concatenative and statically typed programming language
  was Stabel: A pure concatinative programming language, now with modules
  was Stabel v0.2.0-alpha: A pure concatinative programming language, now with modules
  
      Technology Saves the World
  was Andreessen: Technology Saves the World
  
      Why bother with old technology? (2013)
  was Restoration of vintage computers – Why bother with old technology?
  
      What Happens If an Astronaut Floats Off in Space? (2013)
  was What Happens If an Astronaut Floats Off in Space?
  
      Legal expert says Tether and Binance Coin are likely picks for SEC lawsuit
  was Legal expert says Tether and Binance Coin (BNB) are likely picks for SEC lawsuit
  
      If you think psychological science is bad, imagine how bad it was in 1999
  was If you think Psychological Science is bad, imagine how bad it was in 1999
  
      Six charged in Silicon Valley insider trading ring
  was Six Charged in Silicon Valley Insider Trading Ring

Need some description up front, not in the 5th section ("Philosophy" https://github.com/nushell/nushell#philosophy). Some ideas:

"powershell for unix", "structured pipes", "pre-parsed text", "small, useful, typed tools loosely coupled."

powershell for unix is ... powershell: https://docs.microsoft.com/en-us/powershell/scripting/instal...

Am I missing something cool by not looking into PowerShell for Linux? Anyone using it could chime in and share how it improves their workflow? What kind of tools does it bring to the table?

Disclaimer: I use PowerShell on Windows, I've never tried it on Linux, but I don't see why its advantages wouldn't transfer. That being said, I think it's main advantages are:

- Typed object streams, which gives you stuff like autocomplete, IDE support, and generally there's no need to muck about with sed/awk/xargs - Very fast, it's absolutely fine to read a file line by line, and parse it in a script, whereas doing the same in bash/awk is a ton slower than clever use of cat/grep/wc (and a myriad of other tools) - Due to type information being retained, it's a lot easier to figure out what a given script does, without having to know how the output of a given tool looks like, given it's particular command line switches.

This is just my opinion, but PowerShell is a lot more geared toward people like me, who only write a script once in a blue moon/muck about with the build scripts occasionally, while Bash is more geared toward veteran sysadmins who live and breathe this stuff.

Nice summary. It leaves me wonder, though: is the philosophy the same as in Unix world? as in, little independent tools that do one and just one thing. Would those tools also need to be modified to add compatibility with the same typing system that is used by the shell?

Or it follows the opposite mentality and the sell comes with batteries included?

I'm thinking of some arbitrary example, like downloading a JSON and parsing it to obtain some nested sub-property. In Bash world you would use the shell to execute at least something like `wget` to do the download part, and then run `jq` to parse the JSON and select the desired property. Both of `wget` and `jq` are independent programs, installed separately, with their own input & output channels, that you combine together by using the shell itself.

How would this work with PowerShell? (feel free to use some other example that might be better suited)

Powershell commands (called "commandlets" or "cmdlets") are little .net (or .net core) programs/methods which accept and return either objects or arrays of objects, rather than plain text.

powershell offers cmdlets which let you sort and filter these result objects based on object property values rather than sorting on plain text values.

Obviously when printing to stdout or stderr, THAT bit is plain text, but until that very last step of displaying in the terminal, powershell results are objects.

So, that gives you a form of type safety, which isn't strictly possible in text-only shells. Powershell uses reflection to inspect the objects since the exact type of a response may have never been seen before. You can write your own cmdlets which return your own types and you can modify types returned by cmdlets using operators like 'select'. So, it's type-safe but not like everyone is used to. Powershell cmdlets always return objects (or errors, I guess), but the structure of those objects isn't always known until runtime. You can still use those never-before-seen types with the standard operators like sort and select, too.

Powershell also offers output conversion cmdlets which let you output to CSV or a textual table or a list, which is helpful when the next step in your pipe chain is a tool that expects textual input or a csv file. One can also write their own output formatters, of course.

In those ways, powershell and nushell appear to have the same goals. I haven't looked at nushell any more closely than it would take to notice this, so there may be other similarities I haven't noticed, yet. I'm sure there are many differences that I haven't noticed yet, as well.

In powershell you would use built ins.

To download json over rest you would use Invoke-RestMethod or irm.

To convert json to objects you would use ConvertFrom-Json.

To select properties from objects you would use Select-Object or select.

Here is a concrete example that I wrote for the rustlings install script: https://github.com/rust-lang/rustlings/blob/main/install.ps1...

Note that I used Invoke-WebRequest instead of irm here.

I use it a bit on windows servers because it integrates well with other microsoft tools.

On linux...it seems both redundant and just plain weird for weirds sake. There are literally dozens of alternatives on linux that have a sane syntax and are likely preinstalled.

Powershell is a pretty neat scripting language, especially if you manage Windows boxes or have lots of .net stuff around.

It's not a good interactive shell environment though. The commands are way too verbose and the syntax feels clunky for keying in.

I disagree. Yes, the syntax is verbose so that you get sensical names instead of things like 'awk' and 'grep', but that isn't a big deal because a) tab complete[0], and b) user-definable aliases.

[0] tab complete works on cmdlets, switches, and variables.

And if one misses the short incomprehensible aliases, the common commandlets have those by default anyway. `cat` is `gc`, `grep` is `sls`, `ls` is `gci`, ...

Same for switches and parameters. You don't have to miss `rm -rf foo/`, it's just `ri -re -fo foo/`

I don't mind the verbosity at all, but PowerShell in my experience is painfully slow for interactive use, if you want the kind of niceness you can get with Fish, Zsh, or Elvish (fuzzy filtering, smart-case completion, any-order/substring completion, etc.).

The module system is also not great for distributing little configure snippets like Oh My Zsh or something, it's clunky and over-complicated for that.

> [0] tab complete works on cmdlets, switches, and variables.

Isn't this how modern tab complete works everywhere? bash 5.1 (the shell I happen to be running right now, and which I mention because I think of its out-of-box tab completion as pretty basic) tab completes variables.

I don't use it as a shell on Linux/macOS (I don't think it's even really supported yet), but as a scripting environment it's been ok: the language is sane enough, you can use the .NET BCL if you need to and its behavior is consistent across platforms.

We use it for automation in our .NET codebase (which is being developed on both Windows and Linux) instead of bash scripts because of that and the fact it's preinstalled in the .NET SDK Docker images

It's supported on Linux. It's one of the first packages I install on a fresh box lately.

What do you use it for generally ?

I used PowerShell as my main shell for a few years (before WSL existed). My experience is that it's extremely tedious having to relearn every command 'the PowerShell way' if you already know your way around standard Unix commands (and I wasn't exactly a Unix guru either). When WSL dropped I switched and haven't looked back.

The only PowerShell tool I did love was posh-git [0]. Thankfully, someone has ported it to bash/zsh as posh-git-sh [1].

[0] https://github.com/dahlbyk/posh-git

[1] https://github.com/lyze/posh-git-sh

I don't think so. Although, there seems to be small trend, especially with golang utilities - to shift from text toward json - or rather a "worst of both worlds" - docker is a prime example of this, eg:

  docker network inspect webservers -f '{{ range.Containers}}{{.IPv4Address}}{{end}}'

Once tools start down this path, I think powershell, or any shell built around primitives that work on tree structures, make more sense (ie: rather than cut, awk, grep-tools for printing named fields etc).

Must admit, I am no big fan of ps syntax - too verbose for interactive use - too unfriendly for scripting..

If you spend all day immersed in PowerShell on Windows then it might make sense to leverage that familiarity on Linux.

Also if you are managing Azure from Linux or macOS.

Powershell has some interesting ideas about passing around objects rather than just text.

The unix way of text streams and tools to manipulate them are too ingrained that I haven't bothered to get in detail, but I hear some people are fans.

PowerShell from Microsoft is looking too alien on Unix. Just looking at the syntax I already feel uncomfortable.

It's hard for me to criticize it because I haven't used it, but it looks like it was designed by a committee and overdesigned. I.e. it wasn't created from the need, like someone at Microsoft wanted to automate his work and created PS to solve his problem. It looks like some boss decided: "They have shells, so we should have it also. But we will make it much cooler. So, let's gather a committee of 500 of our best managers and let's decide what features it should have".

It looks artificial and inconvenient to me unlike Unix shells. Maybe I'm wrong. But I'm pretty sure that even syntax of PS makes it harder to type the commands. Unix commands are very short (many are 2-4 letters long), all lowercase and do not contain characters which are hard to type (e.g. `-`).

PowerShell was started by a single person, Microsoft's Jeffrey Snover. As the project progressed other designers came on board but Snover remained (and remains) as Chief Architect. The design-by-committee allegation isn't being fair to him.

Part of why PowerShell may seem not quite Unix-like, is Snover didn't just look at Unix as an influence. Snover's professional background included experience with IBM OS/400's CL shell and OpenVMS's DCL, and his experience with both systems influenced PowerShell's design.

Once you start using PWSH, the design decisions are so obvious and make so much sense, that it is obvious Jeffrey Snover did have vast experience with variety of shells and languages.

The idea to tie it with .NET and COM+ on windows is the best a shell has ever done, though someone noted in another thread that it is an old idea from XEROX mainframes (not sure what the name was).

if you want to imagine this in terms of unix/linux - it would be something like having all libraries' APIs at disposal directly from a shell that passes structured objects. or python's REPL being more shell-usable or JVM having a shell that provides access to all classes in a click of ENTER.

major downside of pwsh is that you can feel it being slower than expected due to the way objects are passed around, but I really expect this will be solved at some point with future releases as PWSH as language is still being developed so some concepts and internal architecture decisions perhaps change a lot.

noshell is taking this idea to a fair level, but really, there is a reason to do some dev/devops work in PWSH because it will heavily impact all future shell development even if eventually superseded by something better.

BTW Jeffrey Snover said every PowerShell feature was supported by a business case. A principled approach, I thought, if mercenary.

But what's the "business case" for iteration, conditionals, addition - apart from "everyone needs these"? Though these probably weren't the features he was thinking of.

The only thing I can think of in PowerShell that definitely seems to be "design by committee" is the whole ScriptExecutionPolicy nonsense.

I’m sorry to say this but this is a very uninformed comment with way too many biases without any backing.

> I.e. it wasn't created from the need, like someone at Microsoft wanted to automate his work and created PS to solve his problem

Interestingly enough, it is used for automating Windows configuration.

Re last paragraph:

UNIX commands are random letters that are like that due to historical reasons — if you don’t know one exists, you can’t find it. And when you have to use {} in PS you are dealing with something you would do with awk sed with even more arcane syntax — PS is pretty readable with some knowledge on any PL. Also, they are Verb-Noun based so you can get around and find commands even offline (though Noun-Verb would have probably been a better decision). Due to the fixed syntax they can be shortened very well. Also, due to every “command” having the same conventions, arguments are properly done (no tar xf or -xf or —extract), they are reliably autocompletable without black magic, and they are also autocompletable by giving enough letters to make it unambiguous. So while I am not particularly fond of Microsoft, powershell is better than bash (though frankly, what isn’t?) in every conceivable way.

> So while I am not particularly fond of Microsoft, powershell is better than bash (though frankly, what isn’t?) in every conceivable way.

There are fair criticisms to be made of bash...but this isn’t a fair comment either; I use power shell a lot; I’ve written hundreds or thousands of lines of powershell glue for scripts and devops pipelines and all kinds of things.

It’s not very good.

It is one of those things that seems like it’s a great idea; everything is an object, don’t serialise between jobs, tab completion on related objects, verb-noun commands... it reads like a feature matrix.

The reality is less ideal.

It’s verbose, the commands are arcane, and the verb-noun thing breaks down into meaningless pairs in many cases, particularly in the azure commands, or worse sql server commands.

Maybe, to be fair, there is a core of elegance in there, but powershell displays a fundamental failure:

When an application doesn’t have to do the hard work of making a good cli, the resulting commands in powershell are actively user hostile.

It’s a pattern I’ve seen over and over again; and things like the az-cli are a tangible acknowledgment from Microsoft itself that the results have been substandard, and rejected, overwhelming, by the broader community in favour of arguably inferior tools (eg bash).

So... you might argue “network effect”, but I don’t buy it; powershell isn’t friendly; not to new developers, not to “clicks ops” developers, not to Unix developers.

It’s firmly a middle ground “no one wants to use it if they can avoid it” product.

Bash scripts, now there is literally a hell on earth... but bash itself? Works fine.

/shrug

> It’s firmly a middle ground “no one wants to use it if they can avoid it” product.

No way, I love PowerShell. It was my first choice for the bulk of a B2B Windows integration product. Part of it's a C# desktop app; the rest is PowerShell scripts that customers can edit to taste.

I reach for it all the time in projects. The pipeline is so clean to work with. Once you get used to how it handles collections, the cmdlets are very intuitive, and PowerShell Gallery has a large selection available for download.

Objects instead of strings is big by itself, of course. Then you get the .NET standard library right in the shell to interact with them. Great for parsing dates, numbers; a powerful regex engine; stream manipulation; pathing functions; the ability to write and execute C# in the shell; etc.

The cmdlets for data manipulation have gotten very good, too. The CSV cmdlets used to be unintuitive because they exported type data, but that's now off by default. `Import-Csv` and `Export-Csv` work with objects that you can easily manipulate with the set operations cmdlets. It feels very much like LINQ.

Same with `Invoke-RestMethod` (`irm`) when interacting with APIs. It deserializes JSON into objects automatically. You can then easily filter or transform the result.

There's a learning curve for sure, but once you get past that, it's a very good shell. I feel like it's one of the best things to come out of Microsoft.

I didn’t mean that PS is the ideal shell, it has plenty of warts (I did mention the Verb-Noun thing), and bash’s syntax does have a good subset — namely piping, redirects to a certain degree. But variable substitution, not having proper math support, everything is text are terrible and they do come up with the arguably rare, more complex commands. Also, having a convention that has quite a few edge cases where it doesn’t work good may still be better than not having any. And the application not creating good cli is not shell-specific at all —- the linux world has it better because a good cli is prioritized. Even though git is often touted as having a terrible interface.

This comment would make it into awesome-space, for me at least, if it had some examples of the issues you mention.

Yes, I haven't used PowerShell. And I agree that my comment is uninformed.

It's just that I feel uncomfortable even looking at the PS syntax. Maybe it's idiosyncratic. Maybe I've spent too many years in Unix shell.

If somebody tried to introduce the Unix shell syntax today, they would be laughed out of the room. Nobody would be able to take something so utterly nonsensical seriously.

The only reason anyone accepts it is that it has always been there. But if you actually look at it critically, it is hot garbage.

Idiomatic Powershell is definitely verbose, but you get used to it (and you can disregard if you want). The verbosity can be used to make it more human readable, if done right. I use Powershell on a daily basis - the biggest thing that people have noted is passing objects, instead of text. At first it was weird, but now I find it really helpful. It makes it very easy to tie components together, without having to slice and dice text.

Another great feature is named parameter support. It's so much easier to deal with parameters than with other languages I've used.

I've used it and I can relate to the comment. Maybe your assumptions are off in there, but I think the main point you were trying to make is that it's complicated. It's so complicated that you really need a repl to be able to work with it efficiently. It's a bit like how programming Java is simple if you do it in Idea or back then in eclipse, but in a pure editor it's impossible to remember all the boilerplate.

> They have shells, so we should have it also

The thought process was more like "You can either hire a dude to do it by mouse in MMC or you can get someone with a masters in CS to do it in DCOM. We need a middle ground."

Source: was in the room

Can you elaborate?

Not OP, but: MMC = Microsoft Management Console, the collection of "snap in" GUI config tools for all the advanced features beyond Control Panel.

MMC can control remote computers, but I believe only one at a time? Unless it's something through Group Policy.

Now, the APIs exist to do all this remotely (DCOM), but good luck discovering what they are! And the minimum level of program you'd need to call them would be a C# project.

So, Microsoft knew that UNIX systems had an API that was interactive, scriptable, discoverable, and composable, all the things which CMD and MMC and DCOM aren't. So they decided to build one. And make it object-orientated. It's actually pretty good for the administration use-case, but for more general work it feels weird. And it doesn't interact with text files anywhere near as good as shell does.

I'm sorry, are you a shell user? Since when ~, for example, is easy to type and - is hard to type? LOL.

First of all your backstory is wrong, it was a 1-person project. Then, about the features, all those long, explicit commands have short versions.

Secondly, I agree that Powershell feels a bit alien on Unix, which will probably be the main reason its adoption will never be amazing.

For a long time the Windows equivalent of ~ was %USERPROFILE% which was definitely harder to type than ~. Eventually they introduced the shortcut on Windows too.

Same for me, but looking at nushell, I'm not ruling out that they'll end up with something very similar to it. (I haven't used Powershell much to be honest.)

powershell for unix

In general I really dislike "[some other product] for [a different use case]". It might be accurate but many potential users might never have heard of PowerShell or if they have only have a vague idea of what it is.

I find it hard to believe that someone looking into alternative shells would have never heard of PowerShell. I get that Windows isn’t exactly most people’s OS of choice, but the existence of PowerShell is widely known.

I know that fish shell exists but I have absolutely no idea what distinguishes it from bash or zsh, both of which I use regularly. The extent of my knowledge comes from seeing the name in a HN title.

It's not hard to imagine the same for PowerShell.

The philosophy part reminds me of `jq` with its functional style processing:

1. parse a json value from stdin and set it as the initial result

2. for each function, apply the function to the result, and set the output as the result for the next function.

3. The final result is pretty printed on stdout.

https://codefaster.substack.com/p/mastering-jq-part-1-59c

It used to have a motto that was something like "a shell for the github age", and I guess they never picked something more appropriate.

Kudos for writing something in rust and not appending "written in rust!" everywhere.

Why is everything written in rust nowadays? Apart from the safety it provides.

> Apart from the safety it provides.

Sum types (and pattern matching), first-class results, ownership, good performances and a rich ecosystem turn out to be quite nice for a general purpose langage once you’ve passed the hurdle of the borrow checker, even ignoring all the zero-cost abstraction stuff.

Also the really solid and safe multithreading. You might struggle a bit getting all your ducks in a row, but past that you’re reasonably safe from all sorts of annoying race conditions. And rayon is… good.

Not sufficient for GUI applications where the rust experience remains not great, but for CLI or even TUI?

I’ll misquote something i recently saw on Twitter because it’s very much my experience: “and once again I end up riir-ing a one-off tool I wrote in python and wonder why I didn’t just do that from the start”.

There must be something else, because most of what Rust brings to the table is what functional languages have been providing for ages, just with rebranded names.

Existing functional languages had their own issues:

1. Haskell: had to deal with cabal hell

2. Scala: Java toolchain, VM startup time, dependencies requiring differing Scala versions.

3. F#: .NET was considered too Microsofty to be taken seriously for cross platform apps.

4. OCaml: "That's that weird thing used by science people, right?" - Even though Rust took a decent amount of ideas from it, it got validated by its early users like Mozilla and Cloudflare, so people felt safer trying it.

5. Lisp: I don't think I need to retell the arguments around Lisp. Also a lot of the things Rust touts as FP-inspired benefits around type systems really aren't built into lisp, since it's dynamically typed, these come more from the Haskell/Scala school.

There is truth to that, the "something else" is a different set of trade-offs for some other things that have usually been associated with FP languages.

Rust feels like the love-child of part of ocaml (for the sum types), part of C (very small runtime, ability to generate native code, interrop with C libs, etc..), part of npm (package manager integrated with tooling, large discoverable list of libraries), etc...

Borrow-checking seems a bit newer-ish - but I'm pretty sure there is an academic FP language that pionnered some of the research.

No-one is planning to give Rust the medal of best-ever-last-ever language any time soon.

And none of that is a "bad thing" (tm.)

In my case, I use it because it is dead simple to get a standalone, lean, fast, native executable (on top of the other functional programming features). Cargo is a huge part of what I love about rust.

> most of what Rust brings to the table is what functional languages have been providing for ages

In relatively familiar package & paradigm, with great package management (Haskell is the best of the functional langages there and it’s a mess), and with predictable and excellent performances.

That thing is runtime performance.

I think Cargo doubling as both build tool and package manager is a big factor here. The combination of Cargo + crates.io makes it very easy to write some Rust code and make it available to anyone with Cargo on their system. Either by `cargo install nu` to build it from sources on crates.io or `cargo install` inside the git repo to build my own customized version. No more waiting for distro packagers to keep up.

Putting this together makes for a nice environment to distribute native system tools. And in the last few years we've seen a wave of these tools becoming popular (ripgrep, bat, fzf, broot, exa and some others).

Thank you for listing these. I had a look at them and they are really useful utilities. Now the challenge is to try to change the muscle memory that relies on the traditional unix commands!

How are you measuring popularity?

Popularity in this context is my personal experience seeing these tools pop up over and over again in the media that I consume.

This is insanity and hubris.

"It's so easy!" yes if you have the language and tools de jour installed and up to date. I want none of that.

It was node and npm.

Then go.

Now Rust and cargo.

Oh, I forgot ruby.

And all this needs to be up to date or things break. (And if you do update them then things you are actively using will break.)

I don't need more tamagochis, in fact the less I have, the better.

What happened to .deb and .rpm files? Especially since these days you can have github actions or a gitlab pipeline packaging for you. I can't care less what language you are using, don't try to force it down my throat.

Many of the popular rust cli tools like ripgrep, exa, delta, etc -do- have package manager install options.

How dare people writing cli tools not package them conveniently for my distro. The horror of using cargo instead of cloning the source and praying make/meson/etc works.

Feel free to package and maintain these tools yourself for your distro if you want.

> What happened to .deb and .rpm files?

The problem with those is they require global consistency. If one package needs libfoo-1.1 (or at least claims to), but something else needs libfoo-1.2+, we can't install both packages. It doesn't take long (e.g. 6 months to a year) before distro updates break one-off packages.

I think some people try hacking around this by installing multiple operating systems in a pile containers, but that sounds awful.

My preferred solution these days is Nix, which I think of as a glorified alternative/wrapper for Make: it doesn't care about language, "packages" can usually be defined using normal bash commands, and it doesn't require global consistency (different versions of things can exist side by side, seen only by packages which depend on them).

I'm the parent that you replied to. In my eyes there is nothing wrong with .deb and .rpm files. In fact, many of these tools are available for download in these formats and some others (docker, snap, etc). And it is good that they do but it comes with extra work to setup the pipelines/builds.

The concept of a language-specific package manager distributing not only libraries but also executables isn't new. Go get, ruby bundler, python pip, cargo and npm all have this feature.

I was originally answering a question about why we suddenly see all these "written in Rust" tools pop up. I think that is partly because Cargo provides this easier way to distribute native code to users on various platforms, without jumping through additional hoops like building a .deb, and setting up an apt repository.

Sometimes you just want to get some code out there into the world, and if the language ecosystem you are in provides easy publishing tools, why not use them for the first releases? And if later your tool evolves and becomes popular, the additional packaging for wider distribution can be added.

Ease of use and familiarity are different things. Tooling around rust really is easy, when the alternatives (for equivalent languages) are CMake, autotools, and the like.

As it stands, I can brew install ripgrep and it just works. I don’t need to know it’s written it rust. If, for some reason, homebrew (or whatever other package manager) is lagging behind and I need a new release now, cargo install is a much easier alternative compared to, again, other tools built in equivalent languages

The problem with .deb and .rpm is your dependencies, some things aren't packaged, you end up having to build separate packages for each major Debian and redhat release to link against the correct dependency version.

I'd love that to all be "one-command automated", but I haven't seen such a thing, unlike cargo, which I do find I can be productive with after a one page tutorial.

100% agree. I find it very funny, but in a sarcastic and totally wrong way, when a project's README has an Install section that reads:

  Run "cargo install myProject"

I know Rust, so Cargo is not alien to me. But come on, you know that your install instructions are a bit shitty.

Please, choose a target distro, then test your instructions in a clean Docker container. THEN you can sit down knowing you wrote proper guidance for users.

EDIT because this comment is being misunderstood: I meant that you should make sure your instructions work as-is from a clean installation of your intended distro(s), regardless of how you prefer to do so; using a Docker container is just my preferred method, but you can also do a clean VM or whatever else, as long as you don't assume anything beyond a default installed system.

You happen to have cmake or autotools installed, others happen to have cargo installed.

Once cargo/cmake/autotools/make/npm/mvn/setup.py/whatever runs, the process of taking the output and packaging it for your preferred distro is the same.

There's more work involved if you want a distro to actually pick it up and include it in their repos around not using static linking, but if you're asking for a .deb/.rpm on github actions, that's not needed.

Why don't you download the native binaries then?

Rust isn't an interpreted language, you only need the rust toolchain if you want to build from source.

Ruby requires an interpreter at runtime. JavaScript too. Rust produces standalone binaries. So no, "things don't break" and you only compile things once.

// I can't care less about deb or rpm files so don't try to force that down my throat.

I agree that it's not ideal, but unfortunately bad decisions by Linux distributions and package maintainers have trained me as a user to avoid the package managers if I want up to date software with predictable and documented defaults.

Good package manager, broad ecosystem of packages, no header files, helpful compiler messages. It offers a good alternative to C++ for native applications.

Not to mention excellent support for algebraic datatypes and pattern matching.

So much this. After having encountered ADTs for the first time in Haskell and later on in Rust and other languages, any language without sum types (like Rust's enums) feels wholly incomplete. And the destructuring pattern matching is the cherry on top.

ADT and pattern matching really does it. Older languages certainly have their pull and can do a lot but with many modern coders having an interest or even education in higher level mathematics, easily being able to do that will put you way ahead of the competition. Even the hyper-pure Haskell now runs its own ecosystem and has actual systems written in it.

It's a fast compiled language with a great type system and a sane build system. There aren't a lot of alternatives with those properties.

I'd say the closest are Go, which doesn't have remotely as good a type system, Typescript which isn't compiled and isn't quite as fast or nice.

Most of the answers here omit this, and it's a very important point for hobby open source projects - Rust is just very fun to write.

Backwards compatibility can be a heavy burden for a programming language. C++ could be a much simpler, ergonomic language by eliminating features and idioms that are no longer convenient to use.

Achieving mastery in C++ requires a lot of work. C++ projects require a coding standard. The decision space you have when working in C++ is much larger than when working with Rust due to the proliferation of language idioms.

Rust in the other hand, as a newer language, can benefit from the experiences working with languages such as C++, and provide a better experience right from the beginning. In fact, Rust was created by Mozilla as a response to the shortcomings they perceived in C++.

I just hope that Rust with 40 years of backwards compatibility feels better than C++ today.

40 years is a long time, so the experience will almost certainly degrade a fair bit. The notion of editions in rust makes allowances for breaking changes while still keeping backwards compatibility, I'm very curious to see whether the problems that solves outweigh the complexity in the compiler.

"What have the Romans ever done for us?"

https://youtu.be/djZkTnJnLR0?t=56

Seems like low level programmers finally getting an enjoyable, modern, free language and are getting a bit loose with it!

Also high level programmers getting something more performant and that doesn't require a runtime but still has a lot of ergonomics they're used to.

It’s the new C/C++ but also you can write Rust like you’re writing Golang.

None of that sounds appealing on its own.

Ready for the downvote wave. :D

This is a thread about a shell. That’s very much the sort of project that is typically written in C, and also the sort of project that really benefits from being written in something safer.

It’s fine if writing systems languages doesn’t appeal to you, but they fulfil an important niche in. V8, Hotspot, Cpython all have to be written in something.

I write a lot of personal small utilities in Rust these days: The tooling is more modern than C++, it's more consistent cross platform, and it doesn't suffer the VM startup time of Python, which I would have used previously.

Might just be the Baader-Meinhof effect:

https://en.wikipedia.org/wiki/Frequency_illusion

That is like a big deal. Also speed.

>That is like a big deal

Why you think it is "a big deal"?

"Security bugs" are after all just a specific class of bugs and are still a huge nuisance in non-critical applications as a crash one could leverage for circumventing some security boundaries means most often just a unexplained crash for the common user, which just wants to use a tool in good faith.

So, reducing security bugs means less crashes on weird input, less leaks (better resource usage), just a more stable tool as some classes of bugs (which may or may not be security relevant) are just eliminated completely - that's a big deal as with rust the (runtime-)cost other languages avoiding this is just not there (or much smaller).

Why do you not? No memory leaks, no security issues stemming from such. No random crashes from memory misuse, no issues debugging the issues that exist. It's like a higher level language but lower. You get to do things your way, except when your way is fundamentally unsafe. The code is then easier to debug as it actually describes what's happening and issues are mostly algorithmic, while the application gets a massive boost in reliability and security.

Security is like the issue now, along with reliability. That's what people need and want. Rust offers that.

hype language du jour

In the past it has been Lisp, Python, Haskell, Go, etc.

Downvoting me doesn't make it less true.

Thanks for letting us know :)

It's the new "I use Arch btw". Genuinely kind of tired of it already.

Meh, not really. Something being written in Rust is a feature to me.

This feels extremely like PowerShell, from all the examples, and even cites "draws inspiration from projects like PowerShell", so "a new type of shell" feels very disingenuous unless it has additional novel properties that aren't evident just from these.

There's also no support for variables yet if the page is to be believed, which means there's 0 chance of me using this for more than 5 minutes right now.

(I'm not trying to say this project isn't worthwhile, just that many other people in the thread currently seem to be entirely uncritical.)

> This feels extremely like PowerShell, from all the examples, and even cites "draws inspiration from projects like PowerShell", so "a new type of shell" feels very disingenuous unless it has additional novel properties that aren't evident just from these.

There's HN-style nitpicking, and then there's this.

I'm sorry, but I'm not actually sure what you're trying to express here.

My initial interpretation is that this is a level beyond typical nitpicking, but I'm not sure how that follows?

"A new type of shell" is a bit of marketing text to express the fact that this shell doesn't follow in the footsteps of most other shells (bash, zsh, fish, etc) in terms of treating things as blobs of text (which allows for a number of innovations). The fact that the author even states that it's partially inspired by Powershell demonstrates that he's aware of the similarities (and has in fact cribbed many ideas from it).

Calling his marketing line "disingenuous" comes across as very petty nitpicking that adds nothing of value to the discussion.

Ah, I see. Thank you for explaining.

The part that bothered me was not that they described something that shared some concepts with PowerShell as "a new kind", but that I did not see any illustration of entirely novel features in the examples that followed. As a sibling comment remarked, they feel I'm quite mistaken, and there are very positive distinctions illustrated in the examples, but I took a look at them again, and it's still not clear to me what they mean.

I think I don't see why it's unreasonable for something which advertises cross-platform support to be compared to common shells on all those platforms, not just originally-*ix ones? That is, I think it's totally reasonable for you to think the tagline is justified solely by the differences in those shells, even if I disagree, but I don't see why you think it's unreasonable for me to hold this view?

https://github.com/nushell/nushell#progress

"Nu supports variables and environment variables"

That page was edited an hour ago, so that was presumably a stale example. I'm glad to be wrong!

I came here to say something similar. The question I need answered in the README is - why would I invest time in learning this instead of Powershell?

My muscle memory for bash is pretty strong, but when I have to do Windowsy stuff, I end up picking up a little bit more Powershell each time and find it pretty neat.

So I'd be interested to know what it does differently, and couldn't find that answer.

Have you used PowerShell much? The examples in the Readme make it obvious that it's very different (in a good way).

I use PowerShell extensively, and there are no significant differences in the README examples. They're basically rebranded PowerShell statements.

I see minor syntax differences, for example in the comparison operators. Nothing that would it would be worth losing the .NET BCL or PowerShell's cmdlets for.

I use PowerShell daily, though I do not, for example, develop nontrivial modules for it.

Could you provide an example of what I'm overlooking?

I think to most people who've only used as Powershell as "That windows shell with the blue background and built in unixy aliases", getting into Powershell itself still qualifies as a "new type of shell", so I'm willing to extend that credit to other shells trying the same paradigm.

I'd agree that getting into PS from cmd counts as a new paradigm, or that getting into Nushell without Powershell experience is as well (based on the examples), but at the point where PS has been shipped with Windows by default for many years now, and Nushell runs natively on Windows, I think it's reasonable to disagree with a claim of "a new kind of shell".

I also think it's reasonable for people to say it's justified - there's certainly, as you and others have remarked, a decent argument to be made for that.

But for me, "different from many common shells, but all the same functionality has been bundled in one shell before"* strongly violates my expectations for "new kind of shell".

* - I am not trying to definitively state they have no new functionality, I absolutely have not dug in deep enough, just that I did not see any examples of it, which I would have expected prominently.

I took it to mean that it was a new type of shell from the perspective of unix/osx users who were presumably their target audience, and who are an audience who might either not know what PowerShell is about our discount it is just a "windows thing" and therefore not relevant to their life. So "new" in the sense of "new to you".

You could probably point to just about any technology that claims to be new and pull it apart and find that it is mostly derivative of existing technology and ideas

Sure, all work is theft, for some value of theft, but as I've said in a couple of other replies:

* "all these ideas have been done before, in various places" is one thing, "all these ideas have been done before in one program in the same role on all the same platforms" makes me feel like "new [to users who haven't used this other thing shipped with the OS for years on one of the platforms]" is insufficient to use without more explicit qualifiers

* I may be oblivious and missing some cool example, but the flip side to "all ideas implemented before" is "no new tricks", and when someone describes something to me as "a new type of X", I really expect at least one novel thing or composition of things to be present.

After all, I wouldn't describe TIFF as a "new type of image format" just because many people who haven't touched photo/graphics editing probably haven't encountered it, or IE4 as "a new type of web browser" (now) just because a significant fraction of internet users are not old enough to have used it when it had market share. (When it was first released, Active Desktop, for example, while a security nightmare, was indeed a new thing for almost all users.)

The philosophy section is the most important aspect, in my opinion, because I want to know why I should switch. In other words, show me a better future, and then I'm more likely to try it out.

> Philosophy

> Nu draws inspiration from projects like PowerShell, functional programming languages, and modern CLI tools. Rather than thinking of files and services as raw streams of text, Nu looks at each input as something with structure. For example, when you list the contents of a directory, what you get back is a table of rows, where each row represents an item in that directory. These values can be piped through a series of steps, in a series of commands called a 'pipeline'.

First 60 second impression - this looks like powershell with not-insane syntax. Looks quite revolutionary, it breaks the traditional paradigm for UNIX shells and appears to artfully refine the good concepts in Powershell (which seem to be let down severely - in my opinion - by UX issues.)

What's wrong with the powershell syntax? The long names? Those are optional. I find the idea of short names (for interactive) AND the option of long names very good. Many of these aliases are similar to unix commands (e.g. "cat" instead of Get-Content or "ls" instead of Get-Childitem).

On top of the nice approach to structured output with pipelines, the "cross-OS first" approach is amazing! Very cool to use a modern shell that can fit both Windows and Unix by design (and not through WSL), hell I'm going to try to introduce it to my small company as a standard tool. Hope it's not in a too immature stage, however it looks very shining and promising considering the enthusiast contributors community. I'm in

Funny enough, the new PowerShell fits this description too now that it’s packaged for Linux.

What if we added json output mode to all shell commands? Or at least make some wrappers that parse their unstructured text output into json.

We would be able to use standard pipelines and jq to filter/query outputs, without any custom shells.

Just imagine:

    ifconfig --json | jq '.[] | [.interface, .inet] | @tsv'

You're not the first person to think of that. See Juniper's libxo: https://github.com/Juniper/libxo

It's integrated into a lot of FreeBSD's command line tooling, and is very useful, when it's available.

So a lot of FreeBSD command line tools support JSON output? That's cool! And I wish it was linux...

I am with you in principle - but I still don't get the jq path/filter syntax I'm afraid. I think I'd vastly prefer map/reduce/zip commandlets...

Ed: I'd say from a quick glance that I think I rather prefer nushell to powershell

There is some movement in this direction: e.g. it's possible to do `ip -j addr` today.

Very promising project that I hope it will take off and succeed.

I recently switched to zsh with the addition of oh-my-zsh and I am happy how it has features like auto completion and command validation of some sort, but this could take it to the next level.

I am just afraid to change to it and be disappointed about some incompatibility issues or bugs / crashes.

I will observe and wait until it's quite popular to hop on I think.

Try fish shell. It has auto completion by default and is easy to configure with web interface "fish_config", no need to rely on some community repo like oh-my-zsh. There can be bugs if you set it as default shell but i just append "fish" at the end of my .bashrc :)

It's so interesting - it seems that fish is getting more and more popular lately.

I tried it ~7 years ago and thought it was severely lacking, so I just stuck with zsh and have never really had a reason to look back.

Maybe I'll check out fish again at some point - what features does it have that drew you to it?

Almost everything that you might get from oh-my-zsh is built in and it's _much_ faster. I've been using Fish for a few years now and I love it.

I don't really use `oh-my-zsh`, I just built my own prompt. It's pretty snappy, so I don't feel a huge need to switch, but maybe on a slow day I'll install fish to give it a whirl.

not OP but the two features of fish that stood out for me so much that I make it my default shell on remote servers are

1) the autocomplete suggestion as you type a command [1]

2) scrolling thru commands after partially writing one only shows entries that match the written text

3) knowing if a command will work before pressing enter -- saves from a lot of gotchas.

all of these read like features nice to have but not essential, but when you're using something every day, it's worth it :)

[1]: https://fishshell.com/docs/current/tutorial.html#autosuggest...

I moved from zsh + oh-my-zsh to fish a couple of years ago.

The main reasons were:

1. It had a lot of qol features I liked from zsh _by default_ without requiring a significant config

2. Prebuilt zsh configs like oh-my-zsh have been pretty commonly quite slow in my experience, which fish fixes.

I use Oh-my-zsh too but I hate that it constantly asks me to update itself and it isn't exactly the quickest update either.

Either update automatically in the background or don't tell me about updates at all. Don't constantly nag me when I start new shells!

I used to use oh-my-zsh and never really understood it. Turns out what I mostly wanted was `zsh-autosuggestions` and `zsh-syntax-highlighting` plugins, plus some sane history settings [0]. I've been oh-my-zsh-free for three months, my computers are now less cluttered and more straightforward.

[0]: https://github.com/tasuki/dotrc/commit/e3769134e758d02a947ef...

I also uninstalled it pretty quickly after having tried it. Additionally, I use powerline, fzf, and easy-motion in zsh though.

I had the same issue but your comment made me look up if there is something to do about it. Both things are possible https://github.com/ohmyzsh/ohmyzsh#getting-updates

I started using zsh with oh-my-zsh as it made me realize how powerful, ergonomic and productive my shell could be. I was annoyed by the slowness. I thought of moving to barebones zsh with the few plugins. My colleague suggested that I used prezto. I have been using prezto ever since with my preferred plugins enabled. And, I have been happy with my setup. It has all the features I need without the slowness of oh-my-zsh. I ended up getting all the features of fish shell using plugins. I didn't want to use fish because it's syntax is not compatible with bash which I have to write at work.

Give prezto a try. You might like it.

I wonder if this could be accomplished in a more general way with a fourth standard file descriptor for structured data. stdjson basically.

I see this as requiring considerable work. For JSON, I don't see the payoff (relative to more expressive type systems). JSON was designed to work within different constraints. All in all, this suggests moving beyond JSON.

Sometimes the new ways are best...

I often find that redesigns / rewrites can be transformative. The same benefits less often accrue to incremental changes.

Practically, in my experience, when a group (or organization) is not under a severe time and budget crunch, redesigns seem more palatable. The results are more likely to be simpler, even if they are not as familiar.

What's wrong with plain old stdout? Lots of people do this with JSON (jq, etc.) and CSV or TSV (csvkit, etc.), XML/HTML, and more.

That's how I generate much of the https://www.oilshell.org/ site. It's just a tree of files and various shell commands, some of which I wrote myself.

I do think we need something better than CSV and TSV for tabular data though. They both have serious flaws (not being able to represent values with tabs, etc.!)

I had this thought half a year ago. Anything not to have to parse text make me happy. Though i guess learning to parse command output helps you learn how to parse other text down the line.

A pipe only conveys stdout. You could redirect 4>&1 1>/dev/null, but you'd have to rewrite all tools to generate both stdout and stdjson anyway.

> You could redirect 4>&1 1>/dev/null

For anyone confused by this, 1 is the output to stdout, and 4 is being redirected to where 1 goes, which is stdout. Unrelated to that, 1 (what’s actually being output to stout by the application) is being redirected to /dev/null.

The order of operations matters. If 1 was redirected to /dev/null first, then 4 would also end up in /dev/null. As it stands now, that doesn’t happen.

So you are supposed to read it from right to left? "First take 1 and throw it away. Next put 4 in 1." Is that how it works?

Good one. I did look it up before I posted, too. I’m never 100% sure.

I never really got acquainted with PowerShell. It always felt very clunky to me. But it exists, it's mature, it's cross platform and widely supported.

Maybe I should give PowerShell Core a try.

there's fair amount of comments here (and in other similar posts) which read like:

'nushell is basically a powershell something' 'bash/zsh is better/worse than pwsh/etcshell'

this is very unfair because pwsh allows control over of the all .NET/COM+ available in a system (well, .NET Core only on non-MS, but still).

while nushell stands on its own shoulders or if u like - allows control of other programs executed, but would not easily call into any API that is a language-specific one nor parse its output as structured one.

so when comparing bash, zsh, nushell, pwsh one should take into consideration that these have different foundations and goals even. like perl stands on top of CPAN, all the JVM stuff on top of all classes, etc.

although it is difficult to say why no one has created (to my knowledge) reasonable JVM-based shell, nor a python-based-one, since java targets such a large number of OS/platforms and provides such a broad library. perhaps because people assume that a shell program should follow the UNIX concept of one-program-does-one-thing-only. on the contrary - it would be a killer feature to have nushell be able to natively execute java/python/whatever API calls and use the structured output (like pwsh indeed).

in essence - is very limiting to compare bash to pwsh only in the sense of 'how much can be done with only few characters', because this always leads to very opinionated and biased arguments and eventually discussions taken out of context.

@joseph8th mentioned a shell [1] earlier, that at least at first glance, seems to be a python + bash combination, similar to what powershell does with .net.

[1] https://xon.sh/

I wonder if the pipelining could be added to a regular shell to get its advantages - the cost for me from moving from Bash is too high.

Basically a "cols" command on steroids - making that have some kind of context aware column names (I'm not sure how) and then support expressions would make it work in any shell.

That's basically what Oil's approach is. Oil is POSIX and bash compatible, but it also has Python-like data structures (recursive dicts, lists). And there's also room to add select/filter/sort. We need help :)

https://github.com/oilshell/oil/wiki/Structured-Data-in-Oil

I played with it recently. The interactive part is limited at the moment, but I really like the idea of having operations like sorting and filtering separate from the tools which produce the data. Having these things consistent and available everywhere is a huge cognitive win. I can finally sort and filter `ls` output without having to read the man page. :) "Querying" data feels a lot like SQL in that respect.

Were you not able to before? ls | grep foo | sort is hardly something people normally read the man page for.

This isn't the way I'd sort ls output by date or whatever field. I'd use `ls -l --sort=date` which I guess is what the GP meant with having every tool do their own sorting by field.

In nushell one can just do `ls | sort-by size`

Yes, that is what I mean.

I also like that nushell's table oriented approach displays the column names, and you just use those names for the `sort` command or `where` command etc.

Ah, fair enough. I misunderstood the parent.

Now sort by filesize

File size or file length ?

What is better about this tool than PowerShell?

The README doesn't mention it at all, just that the tool is inspired by PowerShell.

Nothing. Lets be realistic.

Even if it goes mainstream it will be decade behind PowerShell in conceivable future.

While I appreciate the enthusiasm for developing shell, nothing usable here in years to come IMO when I can just use pwsh.

I use this in combination with fish shell and it's been working really well. I can just switch over to `nu` when the task merits; no need to replace my current shell. I can also just run a one-off line like this.

   nu -c "ls | where size > 10b"

I see the value proposition of nushell. I'm wondering if I should also try fish.

May I ask if you switched to fish from zsh? What motivated your change?

Background: I invested some time not too long ago to read zsh docs in detail and customize my own configuration (e.g. instead of using oh-my-zsh). Since then, I've been quite happy with zsh. That said, I'm also open to switching to fish and/or nushell based on recommendations.

I didn’t switch from zsh, but from bash, to fish, primarily because bash was occasionally a bit clunky to use, and there were a lot of things that could be optimized in a modern environment. I settled on fish because it suited what I was looking for: an ergonomic shell that worked well out-of-the-box. Paired with strong community support, clean scripting syntax, and a wide ecosystem, it makes for a really enjoyable shell experience. I haven’t tried zsh, so I can’t compare the two.

I’m happy with fish, and I don’t see much benefit to switching to nu. nu is exceptionally good at one thing: working with data, but lacks features in other areas (auto-completion, scripting, etc.). With time, I can see these features being implemented, but I think they’ll be re-inventing the wheel in a lot of areas that other shells are already good at.

> what motivated your change?

didn't switch from zsh but bash, did it because wanted a bit more features at shell without additional configuration

How does it compare to fish shell (especially fish’s great autocompletion), e.g. why are you not switching completely?

nu is still in its infancy, and currently lacks critical features of other shells, which is why I haven’t switched completely.

As for the future, perhaps a bit brazen, but I’m confident that other shells will introduce the core feature of nu in the near future to stay competitive. I can see fish having a “||” operator and rewrites of a few gnu functions to achieve what nu does natively.

This seems like a missed opportunity to call it "nutshell"!

Looks pretty cool.

Anecdotally, I found switching shell to be more of a challenge than expected - I’ve been using (oh-my-)zsh for years and decided to try fish, but all the little differences were too annoying for me to get used to - I guess you build up a lot of “muscle memory”! That said, I probably just use the same commands most of the time. If you were doing more advanced stuff maybe it makes more sense to invest the time

I think you can achieve most of the fish features in zsh with the help of plugins. The most compelling feature of fish was history substring search. You type something, press up button and you get a command in history with that substring. I used 'history-substring-search' plugin to achieve that. There are also 'syntax-highlighting' and 'completion' plugins which bring fish shell features to zsh. I use prezto for its speed after getting annoyed by oh-my-zsh slowness.

Good tip, thanks!

Shameless plug: zoxide recently added support for Nushell. It's a smarter cd command for your shell (similar to z or autojump).

https://github.com/ajeetdsouza/zoxide

It's such a huge pain to set up bash on windows (it worked fine, very easy on one laptop but I cannot get bash or wsl working on another newer laptop) that I wrote a very basic wrapper for shell scripts that will transform arguments of Linux user land (like cp, mv, rm) to their windows equivalent. This way all you need is python and your "bash" scripts can just work. Sorta. There are a lot of edge cases. But at least it works enough that I can stop trying to figure out how to install bash on windows or what's wrong with my laptop.

I installed wsl on like 10 machines, including "newer laptops", and never had problems with the setup. Instead of solving your actual problem you created a whole new problem domain, that seems... not like the way to go

The "domain" I care about is for basic build scripts to work on Windows and Linux. Whichever way gets me back to regular work is the best way! I do not have the experience to debug when BoW or WSL do not work unfortunately.

while it can be a pain to deal with windows quirks, writing a wrapper script to deal with low level file IO stuff sounds like a good way to open a whole can of worms and irrevocably mess up your whole system

I had problems with WSL on my newer laptop, and it all came down to disabling Secure Boot.

Oh, thanks for sharing. Maybe I'll try that.

What was the problem with WSL? It's been trivial to install on every machine I've tried: work, personal, old, new, upgraded from Windows 7, local account, Microsoft account, etc.

Yes I had that experience until this one laptop, ironically it's a surface laptop. Most likely I screwed some setting up but now no tutorial for bash in windows or wsl works anymore and I have no idea how to work around.

Shameless plug: if you're interested in nushell, you might also be interested in Elvish: https://elv.sh

(And the various other new shells, documented by the author of another new shell, Oil: https://github.com/oilshell/oil/wiki/Alternative-Shells)

This looks pretty awesome. Wonder if it could be used with a command rather than as a new shell.

Tangent: How is this at the top of the front page with a dozen upvotes and no comments? Maybe these upvotes all occurred at once?

It's not uncommon for people to upvote without commenting if they don't have anything to actually add or the post is self-explanatory

Software releases commonly get this treatment, I remember the comment about why there was no discussion on the actual contents of the change on a decently upvoted post about a minor release of wine, for example.

A lot of people just upvote anything that is a GitHub repo because it's generally more useful than actual news

You can with `-c`:

    $ nu -c "sys | get host.name"
    > Ubuntu

On one hand I do like the idea that it's a shell since it means in it's nicely integrated with itself (can't think of a better phrase), but on the other hand it's also what's making me a bit reluctant to seriously consider it because I'm too used to fish.

It would be ideal to me if it were a tool that could be piped into.

However, that's not to say I won't at least give it a try these days, since I'm really curious about it.

I will sometimes upvote something without comment if I found it interesting, don't really have anything useful to say myself, but would be interesting in seeing what other people have to say.

This tracker was a show HN last month, looks pretty normal https://upvotetracker.com/post/hn/27525031

Here is a recent video on Nushell 0.32 features: https://www.youtube.com/watch?v=AqYxhJKblvY

Seems pretty well designed. Though the decision to be able to refer to the properties of data in a pipe directly with their names might cause some confusion in the end (the 'size' in 'ls | where size > 1'). Ok it's succinct, but it's also a bit weird that the loop variable (what this basically is in a pipe) is treated different than all others. Not that e.g. PS' $_ is so great, but at least it's obvious: it's a variable just like all others.

This is a feature that Powershell gained and it is very useful.

My issue with these types of things is always the same. Awesome it does all this stuff I love it, I use it everywhere.

Dev: I have decided to stop working on this project thanks for all the support. If anyone wants to take ownership of it I am willing to transfer its ownership. (Crickets)

Me now after using it for a couple of years have to go back to standard bash or whatever and now people think I have no idea what I'm doing since I forgot so much stuff from lack of daily use.

I don't get these sorts of efforts.

'Let's make something complex appear intuitive by adding more complexity'.

I really respect the work that has gone into this project, but no thanks.

But that can work. Just look at Google: massively complex product and problem, but sure appears pretty simple to the layman - I just type some words into the box and hit enter!

Shameless plug: https://github.com/ngs-lang/ngs - Next Generation Shell

Compared to other modern alternatives, NGS is "programming language first".

Repository of scripts written in NGS, aptly named "NGS Scripts Dumpster" - https://github.com/ngs-lang/nsd

When I think of a new shell I want to understand quoting and the special meaning of characters. Bash has found a decent compromise; what does nu plan to do? The documentation is pretty scant, but perhaps that’s because the language is still developing: https://www.nushell.sh/book/types_of_data.html#strings

Test it with Casey Muratori's benchmark: https://github.com/cmuratori/termbench

Context: https://twitter.com/cmuratori/status/1401761848022560771

That program is for testing terminal emulators, not shells.

Ah, true. Got confused there.

Sort of looks like a modern take on VMS!

It looks very interesting, but the first thing I noticed as a macOS user, is the shell has a built-in command "open" which I expect will conflict with the standard macOS command "open" and I haven't found any docs that describe how to deal with this.

This is true of shell built-ins for eg. test too.

The solution is to use the full path if you want to use the program, not the shell built-in.

In this case, "/usr/bin/open" not "open" will get you the macOS utility. If you get sick of doing that, create a shell alias.

Its not as yet feature complete but has come a long way from its earlier beginnings. I have been using it on Windows and being native and close to UNIX shells really helps my workflow.

The inbuilt commands and structured philosophy is a great approach.

Could someone let me know if https://github.com/akavel/up works ok with it? (on Linux or Mac or WSL) I'd be grateful for feedback!

Similar to "bourne shell" and "bourne again shell" aka bash

I can see the evolution now. "nushell". Next iteration: "nuer shell" (newer) or "renushell" (renew)

Nushell is a new shell. In a nutshell, nushell handles pipes like powershell in a structured data type instead of a string/stream based pipe.

Nushell missed the one feature that every Unix shell has: if it doesn't recognize the first word as a built-in command, look it up and run it as an executable. It's crucial, and nushell is missing out on an ecosystem of random shell commands to complement it as a result. This, of course, is what makes the Unix shell so great: the many little programs able to work together via pipelines.

This makes nushell an interpreter command line, instead of a system shell.

(Yes, you can "escape" by typing ^ before a word. That's not nearly the same thing.)

Its the 2nd paragraph

"If a command is unknown, the command will shell-out and execute it (using cmd on Windows or bash on Linux and macOS), correctly passing through stdin, stdout, and stderr, so things like your daily git workflows and even vim will work just fine."

Argh, how did I miss this. The ^ is just for overriding built-ins with external executables. Apologies!

Clearly I hadn't tried nushell -- this feature I thought missing was a big no for me. I have now, and this is definitely worth a try. Thanks all!

This is how Nushell works. If the command isn't an internal command, it will run it from you path.

Curious what you tried that didn't work.

Heck yah - Very NICE! The demo is what hooked me.

On the face of it this looks like powershell

I use fish for general use, but still write all my scripts with bash. It has worked very well for me.

It's basically powershell

seems nu can do a lot of otherwise horrid sed/awk/cut/etc parsing for bash. that is great!

"A nu type of shell"

That brings a WMI vibe.

What's WMI? Google search says https://docs.microsoft.com/en-us/windows/win32/wmisdk/wmi-st... but I doubt you were talking about that.

https://docs.microsoft.com/en-us/windows/win32/wmisdk/invoki...

This seems very similar to powershell, with far better syntax.

Will fork it as nutshell

It would be nice if the syntax could be very forgiving. So typing something such as 'show me the files over 12 mb' would work. Initially when I read the README it's what I thought it was.

I stopped reading at "rather than thinking of services and input as a stream of text", horrified. Why would we do that ? KISS !

By the same reasoning: Would you not use databases because they have a schema? or JSON...? Heck, even utf-8 could be too complicated.

You have a point. That sounded like pure conservatism, and to some extent it is. But still, text is simple and that what makes shell powerful, trying to move to higher level abstraction is has a chance to create fragmentation and break the solid foundations on which Unix is built.

Because parsing text is shit. Good luck AWK'ing everything. Datastreams are simple.

It's often better than trying to figure out the weird formats all the tool would use otherwise

So start outputting something like json. And render it in the console as an ascii table

Reply on news.ycombinator.com