Beat me to it. A lot of the value in choosing a specific shell lies in its popularity, so I think you really need to have a specific reason to choose something outside of bash/zsh/fish.
> you really need to have a specific reason to choose something outside of bash/zsh/fish
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.
I recommended fish to some my younger coworkers recently only for somebody very senior to point out that they will be very confused copy-pasting commands meant for bash from the internet and them not working. He is right, I will hold off recommending fish. You have to know you are very ready for a new shell.
I think that osh is valuable precisely because of that, since it's bash compatible. The project also has ysh which is not bash compatible, but fixes a lot of shell brokeness, including the #1 source of shell bugs, the need to quote almost 99% of variables and subshell invocations (and not quote them in the rare case you actually want splatting)
I feel like there's a pretty big difference between recommending Zsh and a shell without compatible syntax. The latter assumes you'll spend so much time running ad hoc complex commands in your shell, without opting for a proper scripting language instead, that you'll offset the pains of translating any existing commands to the new shell syntax.
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.
I’d like to see a real shell script written in ion very early in the readme or manual. Something that wgets a tarbal, extracts some part if the filename, checks cpu usage, draws a simple progress bar to the terminal, checks a folder for old files, some script that implements prompt completions for some cli tool…
I really don’t care that a new shell is written in rust. I care to see examples of how it actually would be better than bash.
You get memory safety. That's about it for Security. Quality is in the eye of the beholder. maybe it's quality code? Maybe it's junk, who knows. Rust isn't magic that forces code to be quality code or anything. That said, the code in the Redox system is generally good, so it's probably fine, but that's not because it's written in Rust, it's because of the developers.
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.
While I generally agree, the latest Android report suggests that rust developers get fewer reverts and code reviews are faster. This could mean that better developers tend to adopt rust or it could mean that rust really is a language where quality is easier to attain.
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.
> Rust isn't magic that forces code to be quality code or anything.
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.
Most of the performance penalty for the languages you mentioned is because they're dynamically typed and interpreted. The GC is a much smaller slice of the performance pie.
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.
>You get memory safety. That's about it for Security
Not true, you get one of the strongest and most expressive type systems out there.
One example are the mutability guarantees which are stronger than in any other language. In C++ with const you say "I'm not going to modify this". In Rust with &mut you're saying "Nobody else is going to modify this." This is 100x more powerful, because you can guarantee nobody messes with the values you borrow. That's one very common issue in efficient C++ code that is unfixable.
Sum types (enum with value) enable designing with types in a way otherwise only doable in other ML-based languages. Derive macros make it easy to use as well since you can skip the boilerplate.
Integers of different sizes need explicit casting, another common source of bugs.
Macros are evaluated as part of the AST. A lot safer than text substitution.
Further the borrow checker helps with enabling compile time checking of concurrency.
The list goes on, but nobody that has tried Rust properly can say that it only helps prevent memory safety issues. If that's your view, you just showed that you didn't even try.
It's true for new projects.
For rewrites (such as a shell) it can mean a lot of regressions.
The rust-replacements for coreutils are a good negative example.
The new programs do not reach feature-parity, added regressions, and in some cases also had security vulnerabilities.
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.
Not necessarily. "Quality" and "Security" can be tricky subjects when it comes to a shell. Rust itself is pretty great, but its HN community is made of cringe and zealotry - don't let them dissuade you from trying the language :P
Too bad README doesn't show sample commands, discuss design or list differences from existing shells. So... it's just a shell, in Rust? Like fish, but still WIP? And only for redox-os?
Well, there're samples... in the screenshots. For user info* gotta check the linked manual, which also has a comparison page to POSIX shell[0]. It's basically a slightly different, no doubt improved, POSIX shell. On one hand it's easier to transition to. On other hand it's incompatible enough to create headaches. (And the big competitor is Bash/Zsh not sh.) Considering there're packages for Ubuntu, it is not Redox-only.
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.
Its worth mentioning that this seems to be purpose made to work with an entire custom rust OS Redox-OS. I didn't know that at first glance since I never heard of it. It also answered my question of whats wrong with NuShell?
Have they considered nushell though? It works on both POSIX-like OSes and Windows so it's not platform specific. I'd like to know if it wasn't ready in time (then why not work together instead of starting a new shell, pun not intended) or if there are some technical reasons.
I don't see a single mention of nushell in their readme or mdBook which is a shame.
Readit News
https://github.com/fish-shell/fish-shell/releases/tag/4.0.0
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.
https://oils.pub/osh.html
https://oils.pub/ysh.html
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.
I really don’t care that a new shell is written in rust. I care to see examples of how it actually would be better than bash.
But I assume it's for redox, so you can't use it on a regular linux.
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.
Not true, you get one of the strongest and most expressive type systems out there.
One example are the mutability guarantees which are stronger than in any other language. In C++ with const you say "I'm not going to modify this". In Rust with &mut you're saying "Nobody else is going to modify this." This is 100x more powerful, because you can guarantee nobody messes with the values you borrow. That's one very common issue in efficient C++ code that is unfixable.
Sum types (enum with value) enable designing with types in a way otherwise only doable in other ML-based languages. Derive macros make it easy to use as well since you can skip the boilerplate.
Integers of different sizes need explicit casting, another common source of bugs.
Macros are evaluated as part of the AST. A lot safer than text substitution.
Further the borrow checker helps with enabling compile time checking of concurrency.
The list goes on, but nobody that has tried Rust properly can say that it only helps prevent memory safety issues. If that's your view, you just showed that you didn't even try.
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.
Deleted Comment
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.
[0]: https://doc.redox-os.org/ion-manual/migrating.html
I don't see a single mention of nushell in their readme or mdBook which is a shame.
Ion predates Nushell by few years.
Deleted Comment