Fish is great. NuShell is amazing. But once I start doing such data pipelining, I'd much rather open a Jupyter notebook.
As for why you might use it on Linux, it seems like it's meant to be "friendly" like Fish, but with more emphasis on scripting rather than on interactive use. It looks like a very comfortable scripting language. Something that visually resembles Lua but also has all of the familiar shell constructs would be an excellent scripting language IMO. And that's what this seems to be.
The reason in question is that not that long ago, people said "you really need to have a specific reason to choose something outside of bash", and people choosing to go off the beaten path lead to zsh and fish becoming powerful and way more popular/well-supported than they were before.
Is this true? I don't know Rust so I'm probably missing context. Obvious kudos to OP for writing a shell.
Any GC'd language(Python, JS, Ruby, etc) gives you the same memory safety guarantees that Rust gives you. Of course GC'd languages tend to go a fair bit slower(sometimes very drastically slower) than Rust. So really the memory safety bit of Rust is that the memory safety happens at develop and compile time, instead of at runtime, like a GC language does. So you get the speed of other "systems" languages, like C, C++, etc AND memory safety.
There’s some reason to believe that given how easy it is to integrate testing into the rust code base and in general the trait and class system is also a bit higher quality and it encourage better isolation and things like const by default and not allowing API that could misuse the data structure in some unsafe way. And it has a rich ecosystem that’s easy to integrate 3p dependencies so that you’re not solving the same problem repeatedly like you tend to do in c++
So there is some reason to believe Rust does actually encourage slightly higher quality code out of developers.
It is not, but the language and ecosystem are generally very well-designed and encourage you to "do the right thing," as it were. Many of the APIs you'd use in your day-to-day are designed to make it much harder to hold them wrong. On balance, outside of Haskell, it's probably the implementation language that fills me with the most confidence for any given particular piece of software.
In native-compiled languages (Nim, D, etc), the penalty for GC can be astoundingly low. With a reference counting GC, you're essentially emulating "perfect" use of C++ unique_ptr. Nim and D are very much performance-competitive with C++ in more data-oriented scenarios that don't have hard real-time constraints, and that's with D having a stop-the-world mark-and-sweep GC.
The issue then becomes compatibility with other binary interfaces, especially C and C++ libraries.
Actually Nim2 and Swift both use automatic reference counting which is very similar to using C++’s SharedPointer or Rusts RC/ARC. If I couldn’t use Nim I’d go for Swift probably. Rust gives me a headache mostly. However Nim is fully open source and independent.
Though Nim2 does default to RC + Cycle collector memory management mode. You can turn off the cycle collector with mm:arc or atomic reference counting with mm:atomicArc. Perfect for most system applications or embedded!
IMHO, most large Rust project will likely use RC or ARC types or use lots of clone calls. So performance wise it’s not gonna be too different than Nim or Swift or even D really.
I do not think so. My personal experience is that you can go far in Rust without cloning/Rc/Arc while not opting for unsafe. It is good to have it as default and use Rc/Arc only when (and especially where) needed.
So for battle-proved software I wouldn't say so per-se (if your goal is to replace them).
Nonetheless, if you add truly new rust-code to a new or existing codebase when it's without much of hassle with the interop it should hold.
We’ve been using Rust for about seven years now, and as long as you stay away from fancy unsafe tricks, you really can avoid most memory safety bugs.
I kind of hate to admit, but in many ways Powershell is stil king of the shell game (haha) - the fact that it's object based (with autocomplete!) and has a proper JIT, meaning it's fast enough in processing pretty much anything just with native shell scripts (certainly not true for Bash or Python!) gives it a very different feel. Afaik there are object based shells, but none are fast enough to be generally faster or as fast as the disk is, meaning you need to resort to tricks for heavy-duty processing.
Too bad Microsoft messed up the ergonomics, and using it feels like pulling teeth.
Is there some actual reason to use this? I got sold on `zsh` as it became the standard on the Mac and was packaged by all major distros, but honestly I'm still fine with just plain bash, though I miss the pretty prompts. What is one really getting out of nushell / ion / whatever new tweaked out shell comes out next week?
A: ...in many ways Powershell is stil king of the shell game [but]...
B: Have you tried nushell?
Anyway... nushell is more similar to Powershell (but AFAIK there is no JIT). My default is zsh (as you have mantioned, because of mac) but I use nushell for few things - it is pretty different from bash/zsh/ion/fish. It is more like data pipeline.
I don't see a single mention of nushell in their readme or mdBook which is a shame.
Ion predates Nushell by few years.
In which case, why not just go with nushell https://www.nushell.sh/
Nushell is certainly a better fit to be called modern shell but, even not considering the structured design, is much more different.
*Kinda makes sense as source repos are meant for devs; end-users should be checking manuals/sites instead. We're just used for repos' READMEs to be functionally similar to projects homepages.