Calling the release "The Fish Of Theseus" is just brilliant. I can't think of a better codename for the release of a C++ software that was gradually but completely rewritten in Rust, congrats to everyone involved
A shell is all about producing and parsing strings, which has been a weakness of C/C++ for years. Nasty vulnerabilities like shellshock have turned up in bash. So, if RIIR is more secure and maintainable, it’s a win-win, especially how OSS projects have decades of lifetime across several maintainers
I love the honesty. Number one for reason for using Rust: It's fun. It's a great argument because it circumvents the need to endlessly discuss the logical arguments for safety and robustness vs C/C++ and all that tedious rational stuff. It's not clear to me why people bash on Cargo as being lacking somehow. Likely it is in ways I have not thought of but it seems to me that if Cargo does not help automate a ton of stuff that is not really anything to do with Rust that it is not Cargo's fault. For example it is mentioned here how Fish uses Cmake to automate integration tests and documentation installation etc. I really don't think Cargo should be endlessly extended to try and cover the infinite variety of such jobs.
Cygwin is used in the enterprise. You can deploy your software along with a minimal cygwin package and just have bash scripts regardless of win/linux target.
Started back on KornShell, then BASH, then ZSH. I enjoy using FISH for an interactive shell. It just works well out of the box. You can still run BASH scripts with no issue. Obviously, I would never recommend it for scripts, but it is a nice shell. Obviously, being from the Korn days, I have been more on the C side of things, but I don't have any problems with RUST or the RUST devs I work with. It is cool to see them do this in a year.
@@sodiboo Mainly because I have a ton of bash scripts, and it is what I am most comfortable with. I have done some fish scripts, and it is quite nice, but I don't do many scripts now days, as I get older.
@@Cyco_Nix yeah, that sounds reasonable for why you don't really use it for scripts, but not really an answer to why you would "obviously never recommend it"? that statement sounds like there's something inherently wrong with [non-POSIX?] scripting
@@sodiboo For personal it is fine, but if it is a script you are pushing out to a lot of systems or to other users who may or may not have support for it on the system, then I would want to use something that I know their system has support for.
With the Fish shell, I used to be in the it's not POSIX compliant, so I should not use it camp. But for general shell use, it being the Garuda Linux default, I just kept using it for the tab completion and syntax highlighting. When I decided to finally look into change-ing the shell, I first gave Fish's documentation a read and decided to give it a proper go. And like how Garuda Linux managed to become my preferred choice, I quickly had an 'oh, huh' realisation that I actually liked it. After writing a few scripts with it, I have decided to make all future scripts on my home server in Fish, instead of the current use of Bash. The ways in which the Fish syntax and behaviour differs from POSIX is a major improvement. I am only rarely caught off-guard by the way it interprets data like spaces, instead of in pretty much every script I write like what is the case with Bash.
The way you explained Fish is the way I ended up liking Pamac when using Manjaro. Now; I don't use Manjaro anymore, but I still install Pamac, even though they've abandoned GTK3 in favour for GTK4 + LibAdwaita - I just build the May 7th release (05-07-2023). Now, _of course_ this means in present day I must downgrade Pacman to 6.0.2-9, but this isn't a big deal because I can upgrade Pacman after and symlink in /lib libalpm.so.13 to it references libalpm.so.15 and everything just works with relative sanity after that.
I have written fish scripts at work. It's not a massive challenge, if you are working on a team, to have fish installed. It works on OpenBSD, works everywhere I want it...
5:53 LTS Linux I assume its a paraphrase to describe systems tagged as LTS. And these are not up to date. But if they used the Rust tools, users can update it independent from the system packages (like pip or flatpak does).
I really like fish as my interactive shell. I need no plugins and almost no configuration. Also, I really can't live without its incredible autocomplete anymore.
I have only written a small project in, it was my first (obviously), I was amazed how quickly I picked it up. The compiler is so good with its feedback. I can understand the fan base for it. I love the memory security etc. I think the idea of rewriting in rust would make sense for many. At the end of the day, use the tool that is expedient.
I did that on my system. The chsh thing, not the changing/bin/sh thing. Works great for me so far. I don't use shell scripting enough to remember the syntax of anything, so all those user friendly aspects of fish really help make my life easier when I do.
I don't have much enthusiasm for rewrites, unless the goal is to address real problems that cannot be overcome through incremental work. Alternative implementations, sure, though my preferred language is Go. Actually, as a user I don't really care what the underlying technology or design is; I just need a given tool to fulfill my needs - good CLI/GUI/TUI, good performance, stability and support. Also, the accelerating proliferation of programming languages that often have similar goals but slightly different approaches is an indication that we're all missing something.
I can't think of any languages that have similar goals to Rust. Microsoft started working on a research language inspired by Rust: Project Verona, but they have seemingly abandoned it in favor of just sponsoring Rust development instead.
@@mmstick, Swift would come to mind, or Hylo. Both also try to statically and safely (if possible) deal with lifetimes in a way programmers normally don't need to think about and be a compiled systems language one can use even for kernels (yes, as far as we know, Apple uses Swift in their kernel). Ofc both take a slightly different approach on how to do that, but both should work afaik.
I agree. People see a cursed codebase and go "woah this could be so much better if we rewrite it in rust!!" but they don't know anything about what the code actually does past the surface level requirements and the fact that the cursedness is there for a reason. A from scratch rewrite will crash into the same roadblocks again and have to rediscover unintuitive edge cases and reimplement more or less the same solutions, converging into the same codebase. This is why I believe rewrites are a massive waste of time.
Sure, none of this affects the end user. But, given a c++ code base and “I want to introduce a high level of quality with ownership semantics, remove try/catch exception handling in favor of go or rust’s type based error handling, introduce immutability by default everywhere.” A lot of this fixing around the edges stuff would be more effort to do incrementally in c++ than a rewrite in Rust because these are first class concepts in the language and not bolted onto the side of C++. The language, tools and library ecosystem already provide help in this area. This is a little bit like introducing asynchrony into Java or python. If one function is async, they ALL have to be. Which makes a developer wish they just started with node, where you have to really TRY to make a synchronous function that makes network calls.
all the statements about skill issue and dependency hell sort of reminds me of old memes "just rewrite it in assembly" - do you _have to_ implement every tiniest thing from scratch every time you have to build anything? n.b.: i am guilty of doing so myself, but mostly due to the fact that i find joy in figuring out how stuff works by making the said stuff
Rust exists to solve a problem. If your project benefits by the problems it solves, rewrite your damn program in Rust. Don't worry about it being looked at as a meme. People aren't going to stop using your program because it's written in Rust, but people may start.
Fish is a good shell, but the fact that it's not bourne-shell compatible is REALLY annoying when you're following instructions that assume bourne-shell behavior in quoting and escaping behavior. Still, I liked it as far as it went, and it's good to see that it's still being maintained.
@@moarjank you can easily get around that by adding "[ -x /bin/fish ] && SHELL=/bin/fish exec fish" to .bashrc so it'll leave bash as the login shell but run and set fish as the default shell after logging in.
@@CjqNslXUcMBourne Again Shell will never die. Hundreds of millions of lines of BASH code is in some critical part of a system never updated in the last 20 years.
I've found cargo is particularly a pain to integrate into projects where it is one cog in a larger machine; cargo expects to be *the* build system, and that any tools accepting a binary built by cargo is not going to dictate things like dependencies. I was attempting to bring cargo infrastructure into a buildroot-like project, and have the common dependencies of independent rust packages be version aligned so everything could be dynamically linked and have no duplicates... The amount of wrestling involved told me that this is not what cargo is designed to easily accommodate.
0:45 I am one of those people. Sure, it doesn't exactly play nice with the TTYs too well but it still works fine. It is basically zsh with a couple of the plugins included by default (such as syntax highlighting) and a much nicer and more readable scripting language. I'm also tempted to look into rewriting it in C to troll the Rust devs (maybe I'll use C3).
On Windows, I love cygwin, and use it as my default shell. I have many bash scripts for my Linux machines. With macports gnu bash, I can run them almost unmodified under macos. And likewise with cygwin. I use ssh a lot, and as I understand, you can't ssh into a Windows 11 machine and then get a wsl shell. Under cygwin I use anaconda for heavier python stuff like jupyter and pyside. But having a bash environment in the win32 side of things is something I couldn't easily do without. (e.g. replacing cygwin with powershell would entail rewriting tons and learning different syntax and so on.) I would love up to day rust, rustup, neovim, and perhaps fish under cygwin. But I'm generally happy with bash, since that's available basically everywhere.
13:38 I just now read the KDL website and I think it's immediately my favourite config format. I'll probably use it a lot in upcoming projects as it seems to be exactly what I want.
@@awdsqe123 I saw that on KDL's website. But I know none of the projects they listed as "these use KDL". Seeing that there are actually people using it, maybe it'll become my go-to config language and more wide-spread generally someday.
@@RenderingUser kdl is a little ... too complex for serde, but i can highly recommend the knuffle crate: great errors and a good derive macro. kdl is also apparently very complex to serialize, so in my (admittedly fairly short) search i have not found a rust kdl serializer (though that is less important as a config format). note: kdl is also used by the niri wayland compositor and it is actually quite a good format. niri also uses knuffle. edit: apparently knuffle is unmaintained and there is a more maintained fork called knus. the more you know i guess
Though not having subshells at all is perhaps an oversight. What you write inside command substitutions has side effects. While not a practical example, cd / ; echo ( cd /home/me/bin ) ( ls ) results in the ls being run within /home/me/bin, not /, and the shell being in /home/me/bin as a result. The should have at least a subshell command, so that subshell cd / ls end results in the cd / and ls being run in a subshell, so that the cd / doesn't affect the shell itself. A situation where any command you run can have arbitrary side-effects upon your shell is something that makes me uneasy. (Perhaps an -s or --subshell option on begin might be the answer, so that we could do ( begin -s; cd /; ls ) so that the cd / happens in a subshell.)
Rust is the correct language because the developers concluded that they want to use it and they thought the rewrite was worth their time. If you dislike that, go fork the old version and keep developing it in C++ yourself. I am a C++ developer myself and the criticisms of the Fish devs are for the most part valid. I absolutely understand them not wanting to keep spending their free time fighting with C++' footguns.
Great update. Didn’t have to be rust, but any safe language. That said glad they proved out the rewrite in rust. I hope more software does this and has more tests, better concurrency and is faster.
Same here on Fedora. It used to break something in Gnome but that was years ago. I think most everything that would cause trouble was moved to Systemd, generic .profile stuff, or got a proper shebang.
@foobuilder Oh yeah, and most scripts now have an "#!/usr/bin/env bash" shebang making it also compatible with macOS and nixOS and all the weird unix and unix like distros that don't follow standards
I'm all for it. Not specifically for safety guarantees and fearless concurrency, even tho thats awesome icing on the cake, but because it will remove a ton of legacy debt and workarounds you needed. Rust just doesnt has it, should make it more elegant and be a better foundation for the future.
I'm currently very excited about Rust, and encourage its use (this level of data-race safety is not available in any other language besides Swift and Erlang/Elixer, I think) Rust's governance by foundation can be problematic, but consider the corporate dictatorships of Java/Kotlin/Go/Swift (I'll choose a foundation every time) However, there are safety aspects that even Rust doesn't address (memory leaks, deadlocks, etc), so I'll happily move on to the next language that improves safety without regressing compared to Rust's performance
Memory leaks arent necessarily an issue in Rust. Sure its sloppy when it happens and on extremely limited systems it might cause issues, but leaked memory would never be referenced anyway and thus is not a concern, at least in terms of security.
@@Kiyuja I agree, and I understand how incredibly complicated/limited a language would have to be in order to guarantee no leaks That said, I do think there's a slight safety issue here, as leaking memory could be part of a Denial of Service attack, and factors into overall reliability somewhat I think Rust is currently the world's safest language in its performance category, I just want to be clear that I'm not religiously devoted to Rust, it's the outcomes that I'm excited about, and I'll use any language that provides these (or better) outcomes :)
@@jokeyrhyme yeah I get it. And I'm telling you that memory vulnerabilities that would DOS C/ C++ systems wouldnt take down Rust because (unintentionally) leaked memory cannot be accessed again, this means those attacks dont work. There also cant be buffer overflows and other shenanigans that brought other systems to their knees. Rust has built-in command to intentionally leak memory, this is necessary for systems programming languages, you need leaked memory for a FFI. Funfact: some smaller programs leak memory intentionally at the end, because manually deallocating memory is expensive and operating systems clean it up anyways, so you are done faster as you are skipping a lengthy process.
Some of you might be to young to have witnessed this but back in the day you had to fax invoices if you wanted them paid ASAP. So someone would stand there for a day or two every month and manually fax invoices to their b2b customers. Today most companies accept invoices per email but some others still require them to be sent via fax (time stamps etc) so companies use fax servers and sent them out automatically with all the invoices that go out via email. now imagine someone saying "we shouldnt implement a fax server and should stick with manual work". this example isnt 100% 1:1 when it comes to rust and c++ but its close enough.
More like: I like this new shiny thing, I want this new trendy thing, I am bored and have nothing to do, so I'll use this new thing to get free PR I would not have got otherwise.
@@ruslan_riazantsev while true, no one in this planet wants to use C++. we use it because there is no other language that does what it does and is mature enough.... well there wasn't, now Rust exist. is not even that Rust is a better language... is just that C++ is such miserable experience. one can say the most of last 20 years of programming is literally people coming up with things so they can get away from C++.
I'm passionate about coding in C++ It has its issues, and there are quite a few things about it that make me want to scream at someone, but the syntax is dead simple compared to Rust and it's easy to get into. I've tried to like Rust, but it just isn't for me. It's not bad by any means tho, just doesn't work with how my brain works.
It's not true that fish shouldn't be used as your system shell, I've had it set up (using chsh) for half a year already and haven't found any problems. Scripts usually specify which shell they're written for using shebangs (#!/bin/sh)
@@pixl_xip Nothing particular, just encountering absolutely random problems with absolutely random things. 1.4k issues (270 confirmed bugs) on nushell github kinda proves my point. In my case it included: apps not working at all or in certain conditions, builtins having incosistent/not working/missing APIs and similar. For running scripts that are confirmed to work it might be OK, but at the same time, you can use any scripting language for that. As a daily shell for everything I have very mixed opinions. I do believe in the project, and I really like what they are trying to achieve. My experience is quite fresh (6 months in the past or so).
Mods, rewrite his code base in Rust. Also, we should rewrite fish entirely in Python just because it'll make the Rust rewrite look better by comparison.
Rust seems cool. I've been meaning to learn it. But almost everything I do is either faster/easier in Python, or requires a specific language so I don't get to choose. So I haven't had a use for Rust yet. Maybe someday though...
I love fish. I can’t go back to using anything else. You don’t need add-ons you don’t need to find random projects that have died 10 years ago. It’s just all included. Add on starship a you have a perfect setup. If it works in rust, I’m fine with it too. What I really want is a complete system that’s built around it. No more bash no more zsh. At least personally other than the core system stuff I do not run anything that’s a bash script. And I at least have not for at least five years.
The Rust rewrite meme is still MASSIVE, the fish rewrite's memory usage is so LOW but the rust rewrite is like fixing it with scotch TAPE that's starting to FADE
I prefer msys2/mingw64 (and cygwin by extension) simply because WSL is not portable, once you install via wsl, you gotta recreate it if you change systems which is hurts me for some reason Like the thought that if anything went wrong, my system could be affected by WSL's systems
The 'normal' unix shell language is atrocious, legacy bullshit we are forced to deal with. It should be replaced. And yes, body, I DO want to learn CPP.
As a fellow rust enjoyer - this obviously has my approval. However, let's not get carried away here, rust is just yet another language. If it helps with productivity and brings out more fun from the process, you already have enough justification - you don't need any "um, actually" on top of that.
8:07 I feel these complaints would be easily fixed with some flags and using a more modern C++ standard. But again, gcc, for example, takes ages to support the newer standards. I want to use import already.
If the rust rewrite means I can replace PowerShell with it, I am down. Using Fish as my login shell for my SSH sessions...and I unironically like it. So, this'd be neat.
I have been using fish for a long while now. And I found it the best interactive experience as well. I would love to see if the Rust version behaves differently.
The road to Fish Shell. 1) Bash is ok but, hey,,, zsh seem like goat, I only need these plugins and this ..2) ZSH with plugins is ok but, what, Fish Sell has most of the stuff out-of-the box 3) Enjoy Fish Shell.
Once alternative compilers become available, I'll consider rust to be a good language. However, rustc being the only compiler that's ready at the moment is unfortunately true. C++ is good because there are alternative compilers so if say, GNU does something monumentally stupid, I can switch to another compiler. If the C++ project does something stupid, we can just gradually move away from the language, while not using newer features. If Rust does something monumentally stupid, we can use an older version and move away from it gradually. However, if Rust does something stupid with rustc, we'd be left stuck with an out of date security holes galore ancient compiler. We could fork it, but it would be a nightmare. Imagine if GNOME was the only desktop on Linux at the time of GNOME 3 being released. You'd have MATE, but plenty of other projects were abandoned. It was a nightmare and is not something I want in such an important project as a compiler.
Nice try, but I still refuse to use the shell that requires you to open a web browser to read its documentation instead of using man pages like everybody else.
If you already know the name of the manpage AND the words inside of the manpage you are searching for, this works. Most of the time when I need to look something up, I don't know one of these.
I'm one of those who refuses to use anything other than fish to do anything that doesn't specifically require posix compliance. And moving to rust is AOK with me.
Rust defaults variables as immutability and type. It is fast as it doesn't have or need garbage collection. Rather is an static system that it calls ownership. All in all will not get memory leaks or have to worry about allocation, as developer. Is it better or richer then Python. I think it will be one day, as the compiler is growing and being further developed.
While you won't get double frees, you can quite easily get memory leaks in Rust, it just does reference counting after all (so, have a cycle, and done).
I would love to try using Fish more but in my eyes, Fish is more for the hobby Linux guy that's too much into Linux but doesn't use it professionally (except on their work pc). If I were to use Fish privately and then have to connect to random Linux Servers for work purposes and have to use bash there, I would probably go insane. That's why I will stick to bash
@@viruzaum Yep still in beta but I've started running it the last couple days on Linux Mint from the alt PPA and been very smooth so I expect it'll be release soon-ish
It's no longer Fish, now it's a Crab
the carcinisation continues....
They had a whale of a time rewriting it.
A shrimp
Or turbofish...
crayFish
So the Rust rewrite is now ofishal?
oh fish shell
Yep if you like Betas which are cool fish IMHO. 🤣
what did your spellchecker break?
Goodbye Fish, welcome Fish
fish is dead, long live fish
We got a whole aquarium here
WHOAH, hi gnome!!! I see travelling through spacetime requires some good software, yes. Linux good!
I dont know why, but the idea of "Guys look! Fish is also doing the meme, its looking to rewrite into Rust---, oh its already done." Is hilarious
Calling the release "The Fish Of Theseus" is just brilliant. I can't think of a better codename for the release of a C++ software that was gradually but completely rewritten in Rust, congrats to everyone involved
yeah I made me laugh too
Mascot now named Ferrish? :)
A shell is all about producing and parsing strings, which has been a weakness of C/C++ for years. Nasty vulnerabilities like shellshock have turned up in bash.
So, if RIIR is more secure and maintainable, it’s a win-win, especially how OSS projects have decades of lifetime across several maintainers
Jarvis rewrite Brodie Robertson in rust
struct Brodie {
name: String,
wayland: bool,
distro: String,
wm: String,
rust: String,
}
impl Default for Brodie {
fn default() -> Self {
Brodie {
name: String::from("Brodie Robertson"),
wayland: true,
distro: String::from("Arch BTW"),
wm: String::from("Cosmic"),
rust: String::from("yes please"),
}
}
}
I wheezed
brodie fishton
I love the honesty. Number one for reason for using Rust: It's fun. It's a great argument because it circumvents the need to endlessly discuss the logical arguments for safety and robustness vs C/C++ and all that tedious rational stuff.
It's not clear to me why people bash on Cargo as being lacking somehow. Likely it is in ways I have not thought of but it seems to me that if Cargo does not help automate a ton of stuff that is not really anything to do with Rust that it is not Cargo's fault. For example it is mentioned here how Fish uses Cmake to automate integration tests and documentation installation etc. I really don't think Cargo should be endlessly extended to try and cover the infinite variety of such jobs.
I have no strong opinion on C++ vs Rust, but I love fish so if this makes it better then I'm all for it.
Or just like, make the devs enjoy working on it. That's the most important thing IMHO
Does it though?
@@alxkub They themselves say it does.
@@sparky8251 of course they do, let’s see what users have to say when they finish the rewrite.
I love C++ and question the people that love rust. But I just have no experience with rust, soo....
Cygwin is used in the enterprise. You can deploy your software along with a minimal cygwin package and just have bash scripts regardless of win/linux target.
Started back on KornShell, then BASH, then ZSH. I enjoy using FISH for an interactive shell. It just works well out of the box. You can still run BASH scripts with no issue. Obviously, I would never recommend it for scripts, but it is a nice shell. Obviously, being from the Korn days, I have been more on the C side of things, but I don't have any problems with RUST or the RUST devs I work with. It is cool to see them do this in a year.
why not use it for scripts? i prefer fish for scripting, it's neat and more comfy
@@sodiboo Mainly because I have a ton of bash scripts, and it is what I am most comfortable with. I have done some fish scripts, and it is quite nice, but I don't do many scripts now days, as I get older.
@@Cyco_Nix yeah, that sounds reasonable for why you don't really use it for scripts, but not really an answer to why you would "obviously never recommend it"? that statement sounds like there's something inherently wrong with [non-POSIX?] scripting
@@sodiboo For personal it is fine, but if it is a script you are pushing out to a lot of systems or to other users who may or may not have support for it on the system, then I would want to use something that I know their system has support for.
@@sodiboobecause nobody uses anything except bash to do actual job
With the Fish shell, I used to be in the it's not POSIX compliant, so I should not use it camp.
But for general shell use, it being the Garuda Linux default, I just kept using it for the tab completion and syntax highlighting.
When I decided to finally look into change-ing the shell, I first gave Fish's documentation a read and decided to give it a proper go.
And like how Garuda Linux managed to become my preferred choice, I quickly had an 'oh, huh' realisation that I actually liked it.
After writing a few scripts with it, I have decided to make all future scripts on my home server in Fish, instead of the current use of Bash.
The ways in which the Fish syntax and behaviour differs from POSIX is a major improvement.
I am only rarely caught off-guard by the way it interprets data like spaces, instead of in pretty much every script I write like what is the case with Bash.
Nobody writes serious fish scripts because nobody has fish. Unless you write toy scripts for yourself
@@gronki1 if I share stuff with people, I don't even write shell scripts because it just has way too many edge cases for that
The way you explained Fish is the way I ended up liking Pamac when using Manjaro. Now; I don't use Manjaro anymore, but I still install Pamac, even though they've abandoned GTK3 in favour for GTK4 + LibAdwaita - I just build the May 7th release (05-07-2023).
Now, _of course_ this means in present day I must downgrade Pacman to 6.0.2-9, but this isn't a big deal because I can upgrade Pacman after and symlink in /lib libalpm.so.13 to it references libalpm.so.15 and everything just works with relative sanity after that.
I have written fish scripts at work. It's not a massive challenge, if you are working on a team, to have fish installed.
It works on OpenBSD, works everywhere I want it...
5:53 LTS Linux
I assume its a paraphrase to describe systems tagged as LTS. And these are not up to date. But if they used the Rust tools, users can update it independent from the system packages (like pip or flatpak does).
Pip has been removed from many distros fyi
You should use pipx to install Python apps.
Or just use your package manager if you don’t care about the version
I really like fish as my interactive shell. I need no plugins and almost no configuration. Also, I really can't live without its incredible autocomplete anymore.
still glazing about the autocomplete every time i use it
I have only written a small project in, it was my first (obviously), I was amazed how quickly I picked it up.
The compiler is so good with its feedback.
I can understand the fan base for it.
I love the memory security etc.
I think the idea of rewriting in rust would make sense for many.
At the end of the day, use the tool that is expedient.
Thanks to the efforts of the crab people, fish has been reborn as shellfish
You can chsh your user to use fish with no real issues. However changing /bin/sh to fish would indeed be certifiably insane.
I did that on my system. The chsh thing, not the changing/bin/sh thing. Works great for me so far.
I don't use shell scripting enough to remember the syntax of anything, so all those user friendly aspects of fish really help make my life easier when I do.
I don't have much enthusiasm for rewrites, unless the goal is to address real problems that cannot be overcome through incremental work. Alternative implementations, sure, though my preferred language is Go. Actually, as a user I don't really care what the underlying technology or design is; I just need a given tool to fulfill my needs - good CLI/GUI/TUI, good performance, stability and support. Also, the accelerating proliferation of programming languages that often have similar goals but slightly different approaches is an indication that we're all missing something.
The rust rewrite was addressing real problems through incremental work
I can't think of any languages that have similar goals to Rust. Microsoft started working on a research language inspired by Rust: Project Verona, but they have seemingly abandoned it in favor of just sponsoring Rust development instead.
@@mmstick, Swift would come to mind, or Hylo.
Both also try to statically and safely (if possible) deal with lifetimes in a way programmers normally don't need to think about and be a compiled systems language one can use even for kernels (yes, as far as we know, Apple uses Swift in their kernel). Ofc both take a slightly different approach on how to do that, but both should work afaik.
I agree. People see a cursed codebase and go "woah this could be so much better if we rewrite it in rust!!" but they don't know anything about what the code actually does past the surface level requirements and the fact that the cursedness is there for a reason. A from scratch rewrite will crash into the same roadblocks again and have to rediscover unintuitive edge cases and reimplement more or less the same solutions, converging into the same codebase. This is why I believe rewrites are a massive waste of time.
Sure, none of this affects the end user. But, given a c++ code base and “I want to introduce a high level of quality with ownership semantics, remove try/catch exception handling in favor of go or rust’s type based error handling, introduce immutability by default everywhere.”
A lot of this fixing around the edges stuff would be more effort to do incrementally in c++ than a rewrite in Rust because these are first class concepts in the language and not bolted onto the side of C++. The language, tools and library ecosystem already provide help in this area.
This is a little bit like introducing asynchrony into Java or python. If one function is async, they ALL have to be. Which makes a developer wish they just started with node, where you have to really TRY to make a synchronous function that makes network calls.
all the statements about skill issue and dependency hell sort of reminds me of old memes "just rewrite it in assembly" - do you _have to_ implement every tiniest thing from scratch every time you have to build anything? n.b.: i am guilty of doing so myself, but mostly due to the fact that i find joy in figuring out how stuff works by making the said stuff
LTS linux probably refers to any LTS supported distro since they can use older packages which might cause issues for supporting it.
Rust exists to solve a problem. If your project benefits by the problems it solves, rewrite your damn program in Rust. Don't worry about it being looked at as a meme. People aren't going to stop using your program because it's written in Rust, but people may start.
I am learning C++ not because I was thinking "I want to learn C++" but because "oh god have mercy I need to learn C++ to do this thing"
13:38 kdl is used in zellij config file btw
Fish is a good shell, but the fact that it's not bourne-shell compatible is REALLY annoying when you're following instructions that assume bourne-shell behavior in quoting and escaping behavior. Still, I liked it as far as it went, and it's good to see that it's still being maintained.
It also means it can't parse /etc/profile, which is mandatory on some systems (Gentoo says it is, at least)
In those cases, I just do "bash" and run what I need then exits to Fish again.
@@moarjank you can easily get around that by adding "[ -x /bin/fish ] && SHELL=/bin/fish exec fish" to .bashrc so it'll leave bash as the login shell but run and set fish as the default shell after logging in.
yeah, but on the other hand, the bourne shell is horrible and needs to die more quickly.
@@CjqNslXUcMBourne Again Shell will never die. Hundreds of millions of lines of BASH code is in some critical part of a system never updated in the last 20 years.
Unlimited Rust Works - Universe of Endless Clones
I am the .rs of my shell
Well this one isn't a clone, it's by the fish Devs replacing the prior code
it's much more like mem::replace than .clone
rewrites are good actually. especially for pet projects
Fish pets are really cute
It's standard practice in big tech for mission critical software. Sometimes they even have multiple teams competing for the best implementation.
I've found cargo is particularly a pain to integrate into projects where it is one cog in a larger machine; cargo expects to be *the* build system, and that any tools accepting a binary built by cargo is not going to dictate things like dependencies.
I was attempting to bring cargo infrastructure into a buildroot-like project, and have the common dependencies of independent rust packages be version aligned so everything could be dynamically linked and have no duplicates... The amount of wrestling involved told me that this is not what cargo is designed to easily accommodate.
Niri (scrollable-tiling wayland compositor) uses KDL for config
0:45 I am one of those people. Sure, it doesn't exactly play nice with the TTYs too well but it still works fine. It is basically zsh with a couple of the plugins included by default (such as syntax highlighting) and a much nicer and more readable scripting language.
I'm also tempted to look into rewriting it in C to troll the Rust devs (maybe I'll use C3).
The Rust consumes
You will be assimilated.
Resistance is futile.
you will be oxidated
Corrosive?
On Windows, I love cygwin, and use it as my default shell. I have many bash scripts for my Linux machines. With macports gnu bash, I can run them almost unmodified under macos. And likewise with cygwin. I use ssh a lot, and as I understand, you can't ssh into a Windows 11 machine and then get a wsl shell. Under cygwin I use anaconda for heavier python stuff like jupyter and pyside. But having a bash environment in the win32 side of things is something I couldn't easily do without. (e.g. replacing cygwin with powershell would entail rewriting tons and learning different syntax and so on.) I would love up to day rust, rustup, neovim, and perhaps fish under cygwin. But I'm generally happy with bash, since that's available basically everywhere.
13:38 I just now read the KDL website and I think it's immediately my favourite config format. I'll probably use it a lot in upcoming projects as it seems to be exactly what I want.
Zellij, a tmux alt, uses KDL and I always find it pleasant to write in.
@@Lampe2020 if serde supports it I'll try to add it to my programs as well
@@awdsqe123
I saw that on KDL's website. But I know none of the projects they listed as "these use KDL". Seeing that there are actually people using it, maybe it'll become my go-to config language and more wide-spread generally someday.
@@RenderingUser kdl is a little ... too complex for serde, but i can highly recommend the knuffle crate: great errors and a good derive macro. kdl is also apparently very complex to serialize, so in my (admittedly fairly short) search i have not found a rust kdl serializer (though that is less important as a config format).
note: kdl is also used by the niri wayland compositor and it is actually quite a good format. niri also uses knuffle.
edit: apparently knuffle is unmaintained and there is a more maintained fork called knus. the more you know i guess
i too am looking forward to when uutils rust rewrite officially replaces the traditional gnu utilities implementation.
Oh no, that won't happen. If anything it should be more of a unix utils, as GNU is bloated >:(
But there already are gnuutils in rust so...
I've just installed beta1 of fish4, and am starting to like it. git branch and it understands stuff. I could get used to this.
Though not having subshells at all is perhaps an oversight. What you write inside command substitutions has side effects. While not a practical example,
cd / ; echo ( cd /home/me/bin ) ( ls )
results in the ls being run within /home/me/bin, not /, and the shell being in /home/me/bin as a result. The should have at least a subshell command, so that
subshell
cd /
ls
end
results in the cd / and ls being run in a subshell, so that the cd / doesn't affect the shell itself. A situation where any command you run can have arbitrary side-effects upon your shell is something that makes me uneasy.
(Perhaps an -s or --subshell option on begin might be the answer, so that we could do ( begin -s; cd /; ls ) so that the cd / happens in a subshell.)
Rust is the correct language because the developers concluded that they want to use it and they thought the rewrite was worth their time. If you dislike that, go fork the old version and keep developing it in C++ yourself. I am a C++ developer myself and the criticisms of the Fish devs are for the most part valid. I absolutely understand them not wanting to keep spending their free time fighting with C++' footguns.
Should rewrite curl in Rust, so people will stop opening AI generated bug reports for buffer overflows.
Funny you should say that, since the HTTP networking code for cURL is now in Rust 💀
Great update. Didn’t have to be rust, but any safe language. That said glad they proved out the rewrite in rust. I hope more software does this and has more tests, better concurrency and is faster.
Fish works just fine as default shell for me.
It works as long as you don't replace /bin/sh with a symlink to fish
@@michawhite7613who is fool enough to do that?
Yeah and neither would replacing /bin/sh with a link to /bin/bash… so what?
@threddast That would be fine actually. Arch Linux does that by default.
There has been a lot of work for backwards compatibility lately which I am a huge fan of
"It should never be used as your main shell."
I've been using it as my main shell for months.
You've probably been using it as the shell in your terminal
@@BrodieRobertson I'm serious lol
Same here on Fedora. It used to break something in Gnome but that was years ago. I think most everything that would cause trouble was moved to Systemd, generic .profile stuff, or got a proper shebang.
@foobuilder Oh yeah, and most scripts now have an "#!/usr/bin/env bash" shebang making it also compatible with macOS and nixOS and all the weird unix and unix like distros that don't follow standards
@@BrodieRobertson In my terminal I use nushell by default, but fish is my actual login shell and i've had zero issues.
I'm all for it. Not specifically for safety guarantees and fearless concurrency, even tho thats awesome icing on the cake, but because it will remove a ton of legacy debt and workarounds you needed. Rust just doesnt has it, should make it more elegant and be a better foundation for the future.
I'm currently very excited about Rust, and encourage its use (this level of data-race safety is not available in any other language besides Swift and Erlang/Elixer, I think)
Rust's governance by foundation can be problematic, but consider the corporate dictatorships of Java/Kotlin/Go/Swift (I'll choose a foundation every time)
However, there are safety aspects that even Rust doesn't address (memory leaks, deadlocks, etc), so I'll happily move on to the next language that improves safety without regressing compared to Rust's performance
Memory leaks arent necessarily an issue in Rust. Sure its sloppy when it happens and on extremely limited systems it might cause issues, but leaked memory would never be referenced anyway and thus is not a concern, at least in terms of security.
@@Kiyuja I agree, and I understand how incredibly complicated/limited a language would have to be in order to guarantee no leaks
That said, I do think there's a slight safety issue here, as leaking memory could be part of a Denial of Service attack, and factors into overall reliability somewhat
I think Rust is currently the world's safest language in its performance category, I just want to be clear that I'm not religiously devoted to Rust, it's the outcomes that I'm excited about, and I'll use any language that provides these (or better) outcomes :)
@@jokeyrhyme yeah I get it. And I'm telling you that memory vulnerabilities that would DOS C/ C++ systems wouldnt take down Rust because (unintentionally) leaked memory cannot be accessed again, this means those attacks dont work.
There also cant be buffer overflows and other shenanigans that brought other systems to their knees.
Rust has built-in command to intentionally leak memory, this is necessary for systems programming languages, you need leaked memory for a FFI.
Funfact: some smaller programs leak memory intentionally at the end, because manually deallocating memory is expensive and operating systems clean it up anyways, so you are done faster as you are skipping a lengthy process.
Some of you might be to young to have witnessed this but back in the day you had to fax invoices if you wanted them paid ASAP. So someone would stand there for a day or two every month and manually fax invoices to their b2b customers. Today most companies accept invoices per email but some others still require them to be sent via fax (time stamps etc) so companies use fax servers and sent them out automatically with all the invoices that go out via email.
now imagine someone saying "we shouldnt implement a fax server and should stick with manual work".
this example isnt 100% 1:1 when it comes to rust and c++ but its close enough.
Its not that big of a change in tooling, more like switching to a new bike with a more robust casing around the chain
i have no idea what you talking about
More like: I like this new shiny thing, I want this new trendy thing, I am bored and have nothing to do, so I'll use this new thing to get free PR I would not have got otherwise.
Yeah, c++ is still doing the actual job. Rust is a toy
@@ruslan_riazantsev while true, no one in this planet wants to use C++.
we use it because there is no other language that does what it does and is mature enough.... well there wasn't, now Rust exist.
is not even that Rust is a better language... is just that C++ is such miserable experience. one can say the most of last 20 years of programming is literally people coming up with things so they can get away from C++.
Can we talk of carcinisation here ?
I'm passionate about coding in C++
It has its issues, and there are quite a few things about it that make me want to scream at someone, but the syntax is dead simple compared to Rust and it's easy to get into.
I've tried to like Rust, but it just isn't for me. It's not bad by any means tho, just doesn't work with how my brain works.
It's not true that fish shouldn't be used as your system shell, I've had it set up (using chsh) for half a year already and haven't found any problems. Scripts usually specify which shell they're written for using shebangs (#!/bin/sh)
I shouldn't set Fish as my system shell? Fine, I'll set it to Nu.
I did. Used for 5 months, wrote scripts, and surrendered. This project is still half-baked. In 3 years... Maybe...?
@@soanvig Curious - what were your problems with it? I have been trying it for the past two days, and have really liked it.
@@pixl_xip Nothing particular, just encountering absolutely random problems with absolutely random things. 1.4k issues (270 confirmed bugs) on nushell github kinda proves my point. In my case it included: apps not working at all or in certain conditions, builtins having incosistent/not working/missing APIs and similar. For running scripts that are confirmed to work it might be OK, but at the same time, you can use any scripting language for that. As a daily shell for everything I have very mixed opinions.
I do believe in the project, and I really like what they are trying to achieve.
My experience is quite fresh (6 months in the past or so).
but why?
@@night_h4nter ¯\_(ツ)_/¯
Mods, rewrite his code base in Rust.
Also, we should rewrite fish entirely in Python just because it'll make the Rust rewrite look better by comparison.
Rust seems cool. I've been meaning to learn it. But almost everything I do is either faster/easier in Python, or requires a specific language so I don't get to choose. So I haven't had a use for Rust yet. Maybe someday though...
lol 10:49 brodie just totally hallucinated that "I do know one person though, would love to work on a C++ codebase in my free time". xD
Oh I suppose it's time to give it a new name. Hmm. Taking a note out of bash's book, maybe this should be called fash?
...Ah.
i'd go for rash.
Bish
what's wrong with fash?
Fust
@ It’s an abbreviation of fascist haha
I love fish. I can’t go back to using anything else. You don’t need add-ons you don’t need to find random projects that have died 10 years ago. It’s just all included.
Add on starship a you have a perfect setup.
If it works in rust, I’m fine with it too.
What I really want is a complete system that’s built around it. No more bash no more zsh. At least personally other than the core system stuff I do not run anything that’s a bash script. And I at least have not for at least five years.
Is Git-Bash not based on Cygwin?
The Rust rewrite meme is still MASSIVE, the fish rewrite's memory usage is so LOW but the rust rewrite is like fixing it with scotch TAPE that's starting to FADE
Missed opportunity to rename to ShellFish. 😞🦀
I prefer msys2/mingw64 (and cygwin by extension) simply because WSL is not portable, once you install via wsl, you gotta recreate it if you change systems which is hurts me for some reason
Like the thought that if anything went wrong, my system could be affected by WSL's systems
I'm also really surprised that there is no rust project to extend cargo to be able to do the things fish and others need!
The 'normal' unix shell language is atrocious, legacy bullshit we are forced to deal with.
It should be replaced.
And yes, body, I DO want to learn CPP.
As a fellow rust enjoyer - this obviously has my approval. However, let's not get carried away here, rust is just yet another language. If it helps with productivity and brings out more fun from the process, you already have enough justification - you don't need any "um, actually" on top of that.
8:07 I feel these complaints would be easily fixed with some flags and using a more modern C++ standard.
But again, gcc, for example, takes ages to support the newer standards.
I want to use import already.
Using fish as default shell, happy about rewrite, love&hate relationship with Rust.
Comment for algorithm, just as you desire, Lord Brodie.
I'm hoping that cargo gets cli tools for making deployments and packaging and releases. It is a really big gap in the tooling.
I’ve been using fish as my login shell for many years now and never had any problems with it.
Rustup is indeed magic
I'm half disappointed that the title doesn't say "Rebourne Again"
Awesome video! Much appreciated 💜
Considering so many of the arguments for rust boil down to “it’s the current fad” I wonder what happens when it’s not.
If the rust rewrite means I can replace PowerShell with it, I am down. Using Fish as my login shell for my SSH sessions...and I unironically like it. So, this'd be neat.
as a fish user and a rust dev...
i wonder if i'll see many rust integrations :3
I use fish (non rust i think) mainly for command completion with tab.
I have been using fish for a long while now. And I found it the best interactive experience as well. I would love to see if the Rust version behaves differently.
It's only natural that it has the best interactive experience. It is after all the "Friendly Interactive SHell".
The road to Fish Shell. 1) Bash is ok but, hey,,, zsh seem like goat, I only need these plugins and this ..2) ZSH with plugins is ok but, what, Fish Sell has most of the stuff out-of-the box 3) Enjoy Fish Shell.
4) need to do anything complex, move to nushell
Unrelated: are you still planning on releasing videos on Odysee?
now replace the cmake with meson
Fish works fine as your users shell (aka system shell, changed via chsh). Have been daily driving it this way for more than three years.
The person who wrote this blob post is a great communicator.
Fish is absolutely amazing as an interactive shell. It makes using the terminal much less cumbersome
The only issue I have ever run into with fish is needing to change the syntax for things that would use $ in bash.
Once alternative compilers become available, I'll consider rust to be a good language. However, rustc being the only compiler that's ready at the moment is unfortunately true. C++ is good because there are alternative compilers so if say, GNU does something monumentally stupid, I can switch to another compiler. If the C++ project does something stupid, we can just gradually move away from the language, while not using newer features.
If Rust does something monumentally stupid, we can use an older version and move away from it gradually. However, if Rust does something stupid with rustc, we'd be left stuck with an out of date security holes galore ancient compiler. We could fork it, but it would be a nightmare. Imagine if GNOME was the only desktop on Linux at the time of GNOME 3 being released. You'd have MATE, but plenty of other projects were abandoned. It was a nightmare and is not something I want in such an important project as a compiler.
Currently rewriting my life in rust
My life is filled with too many shared mutable borrows to rewrite it in rust. Checker can't handle the required optimisations, it's all unsafe.
Nice try, but I still refuse to use the shell that requires you to open a web browser to read its documentation instead of using man pages like everybody else.
The future is now oldmann
If you already know the name of the manpage AND the words inside of the manpage you are searching for, this works.
Most of the time when I need to look something up, I don't know one of these.
if i didn't write my software in C++ you couldn't re-write it in Rust, you guys need me 😈
Damn that's a good point lol
Complete rewrite in Rust, 1200 scripts, 961 completions, 217 associated functions, 130 pages of documentation - and still not POSIX compliant 🤣
Me! I swear by fish!
It was a rusty venture, but it was worth it
I'm one of those who refuses to use anything other than fish to do anything that doesn't specifically require posix compliance. And moving to rust is AOK with me.
MEMORY SAFETY IN MY SHELL? OOOOOOOOOOOOHHHHHHHH YAS.
"Where are the C++ evangelists?" Hyprland dev must be punching air right now.
8:35 "It's just, like, part of the language" I don't know why, but the delivery on this cracked me up. 😂
10:53 is this a vaxry reference?
you should download your recovery codes or add a passkey
5:53 According to the very first comment on the initial RiiR pull request, they typically support older versions of CentOS and Debian.
C++ is so difficult I love it. Rust is disgustingly easy.
WHY ISN'T THIS VIDEO ON ODYSEE?
Rust defaults variables as immutability and type. It is fast as it doesn't have or need garbage collection.
Rather is an static system that it calls ownership. All in all will not get memory leaks or have to worry about allocation, as developer.
Is it better or richer then Python. I think it will be one day, as the compiler is growing and being further developed.
Comparing it to python is nonsense, completely different language goals
@@alexstone691 Well it was compared here to C++. Python also compiles and creates executables or libs. So please explain the 'nonsense'?
@@vilijanacPython is not a systems programming language, Rust and C++ are.
@@vilijanac Python is an interpreted language. And yes, it has completely different goals from Rust, there's no need to compare the two.
While you won't get double frees, you can quite easily get memory leaks in Rust, it just does reference counting after all (so, have a cycle, and done).
I would love to try using Fish more but in my eyes, Fish is more for the hobby Linux guy that's too much into Linux but doesn't use it professionally (except on their work pc). If I were to use Fish privately and then have to connect to random Linux Servers for work purposes and have to use bash there, I would probably go insane. That's why I will stick to bash
as an actual fish enjoyer who also refuses to use anything else i can confirm this behaviour unironically
I used to use nu shell before finding fish. Now fish is been rewritten in rust... and I'm okay with that.
I use fish, but none of my distros has updated it to 4 yet, I expect it to be good!
I don’t think any distro has it, it’s in beta
@@viruzaum Yep still in beta but I've started running it the last couple days on Linux Mint from the alt PPA and been very smooth so I expect it'll be release soon-ish
Fish-shaped rust (sounds like a portal cake recipe ngl)