25 ms·

Fish – Update on the Rust port

335 points by rhim 3y ago

behnamoh 3y ago
one of the fastest shells out there will probably get even faster. ever since I switched from zsh to fish, my terminal productivity has gone up a lot.
- bayindirh 3y ago
  I don't think C++ and Rust has that big of a performance difference. They are probably neck to neck with no clear winner.
  - LoganDark 3y ago
    The real difference is in compile-time abstractions. It's much easier to organize things in Rust, especially with a borrow checker. You can confidently remove overhead while being sure that it'll continue to be memory safe.
    - bayindirh 3y ago
      With some strong design decisions, and with modern C++ facilities, you can make sure that your code never does funny things in C++, too. Yes, Rust's BC is a great technology, but C++ is not a runaway nuclear fire which contaminates and melts everything around it when it comes to sanity and security. Yes, Rust allows you to run amok by not allowing it, but you can design a good foundation to your code which prevents tons of problems out of the gate in C++, and this is without using smart-pointers and other things available to you.
      - pdpi 3y ago
        > but you can design a good foundation to your code which prevents tons of problems out of the gate in C++, And there is an almost perfect overlap between the people capable of pulling off a rewrite like this and the people who would write a good C++ foundation in the first place.
      - LoganDark 3y ago
        > Yes, Rust's BC is a great technology, but C++ is not a runaway nuclear fire which contaminates and melts everything around it when it comes to sanity and security. I never meant to imply such a thing. However, Rust is simply a much better-defined language. Moves do what you expect, smart pointers work like you'd expect, there are not 3 (or 5) different types of constructors you have to understand and implement properly if you want to build your own abstractions. You don't have to remember where to put std::move, you don't have to remember what happens to the variable after you move out of it, you don't have to use the awful variant accessor functions if you want a tagged union and so on. Yes, you can do all this in C++. You can build safe abstractions. You can build layers on top of the STL to make it less awful. You can make use of modules and #embed and other nice new features that C++ is getting. But you need to be a lot more careful compared to Rust, because the compiler is not going to help you.
      - Matumio 3y ago
        > C++ is not a runaway nuclear fire which contaminates and melts everything around it when it comes to sanity and security. Not sanity, maybe. But security? How much more would it take to declare a nuclear meltdown: https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...
  - joshlk 3y ago
    In Rust it’s easier to leverage external crates/libraries that are more optimised than rolling your own. This can lead to performance increases (I don’t know if fish is doing this)
    - starcraft2wol 3y ago
      C programs without libraries tend to be really fast for the opposite reason. So this isn’t persuasive even though it seems like it should be true
      - acdha 3y ago
        This is only true for very simple single-threaded code. Once you’re doing anything the compiler can’t trivially optimize, you’re using libraries, getting left far behind by the Rust program, or both.
        starcraft2wol 3y ago
        Since most industrial software is in C and C++ an example would be more convincing. > doing anything the compiler can’t trivially optimize What does compiler optimization have to do with libraries? > single threaded Plenty of C and C++ programs are multi threading using a system api like pthreads.
        acdha 3y ago
        > Since most industrial software is in C and C++ an example would be more convincing. Agreed- do you have any to back up your original claim? > > doing anything the compiler can’t trivially optimize > What does compiler optimization have to do with libraries? One of the most common reasons to use a library is because it has optimizations you want to use. For example, performance-sensitive programs link against OpenSSL even if they’re just using a couple of hash functions because the SHA-256 function you copied into your codebase won’t have their assembly backend or use of processor intrinsics. Repeat for string searches, pattern matching, all kinds of math, etc. where people have written libraries with pricessor-specific assembly, SIMD intrinsics, etc. > Plenty of C and C++ programs are multi threading using a system api like pthreads. Yes - and the long history of bugs related to that is why many stayed single-threaded because it was more work than the author had time for to make the code thread-safe. Rust’s “fearless concurrency” talk isn’t just marketing but a reaction by people with a lot of experience in the area realizing just how much more they used concurrency when it was easy to do correctly rather than infamously hard.
  - andrewaylett 3y ago
    The advantages of Rust come when trying to do complex things with concurrency, and wanting to know that they're either going to be safe, or fail to compile. Consider the now-classic "Fearless Concurrency" post about Stylo: https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I... Strictly, C++ pretty much has to be no slower than Rust. But it's certainly possible that a regular human might in practice write higher-performing parallel code when using Rust.
    - ordu 3y ago
      At the same time Rust forbids some practices pushing a coder to choose another path. To name a specific example, try to roll out your own dynamically sized type type or a self-referential one. Such small things could contribute to performance too.
      - andrewaylett 3y ago
        Yes, there are definitely things one may do in C++ that aren't possible in Rust. In the absence of bugs, I think you could pretty much recreate any Rust program in C++ and have it be just as fast. Of course, you can't assume the absence of bugs in real world software. The C++ version would lack any of the safety added by Rust's compile time checks.
- nick__m 3y ago
  I would not bet on this! from the link : We have no real idea what the performance of the finished port is going to be. Early results are encouraging, but it is entirely possible this will be ~20% slower in some cases.
  - tubthumper8 3y ago
    This part also seems relevant: > Fish also uses threads, for things like the autosuggestion and syntax highlighting, and we would like to have more "threads"/"concurrency"/"run-thing-in-backgroundness" (please insert the correct term here, I have never been good at these things). One large project has been to run multiple fish builtins and functions "at the same time", to enable things like backgrounding functions (ideally without using "subshells" because those are an annoying environment boundary that shows up in surprising places in other shells), and to simply be able to pipe two builtins into each other and have them actually process both ends of the pipe "simultaneously". > C++ offers few guarantees on what can be accessed from which thread. @ridiculousfish has been trying to crack this for years, and hasn't been confident enough in his solution. We want a tech stack that helps us here, and C++ doesn't. The initial rewrite may be no faster, or possibly slower as stated, but long-term they'd be able to safely add more concurrency or parallelism that they weren't able to before.
    - nick__m 3y ago
      I completely agree like someone cleverer than me said : It is easier to make correct program faster than making a fast program correct!
- fbdab103 3y ago
  Is shell performance a limitation for some workflows? I naively think of it as some glue which shunts the work elsewhere. Maybe in the efficiency of pipe? I suppose those lunatics who write full programs in bash? I will always take faster code, but that seems like an odd bulletpoint to highlight given the many quality of life improvements fish has to offer.
  - kstrauser 3y ago
    Kind of, yeah. When I used zsh, oh-my-zsh made the shell startup a lot slower, even though I wasn’t going crazy with the customizations. Opening a new terminal tab would take a couple seconds to get a prompt. My current fish setup is imperceptibly fast to start. Those little delays add friction. Not an intolerable amount, sure, but it’s there. While I switched to fish for other reasons, that alone would keep me from going back now.
    - lkbm 3y ago
      I once spent a while adding timings between each item in my zsh config files to find what was slowest. The nvm init was the worst of it, so now I have an alias for `$NVM_DIR/nvm.sh ] && \. "$NVM_DIR/nvm.sh" && \. $NVM_DIR/bash_completion` I just run manually before using nvm, rather than letting it slow me down half a second or whatever it was every time I open a new terminal. It's worth poking around if things get slow enough to be a pain. There's a decent chance it's 1-2 things that you don't even care about all that much.
      - paradox460 3y ago
        You might check out rtx[1] Its an asdf[2] rewrite, in rust, that can do most of the things nvm can [1] https://github.com/jdx/rtx https://github.com/jdx/rtx [2] https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf
      - dividedbyzero 3y ago
        fish actually has a built-in profiler for its startup that can be enabled via an argument: > --profile-startup=PROFILE_FILE > Will write timing for fish startup to specified file.
- bch 3y ago
  > one of the fastest shells out there will probably get even faster […] my terminal productivity has gone up a lot. Surely you’re not typing and managing jobs at a pace where C vs C++ vs Rust vs $lang matters… or I’m missing something about what fish is bringing to the table.
- deleted 3y ago
  [deleted]
cube2222 3y ago
1. It's amazing that they're doing this as a gradual C++ to Rust rewrite, while keeping it working end-to-end, if I understand correctly. 2. It's amazing how quickly this is going. 3. If you haven't tried fish yet, make sure to do so! It's a really ergonomic shell and overall very pleasant to use, with good defaults (you don't have to customize it, even though you can, for a great experience). I've switched from bash a couple years ago and haven't looked back since. Bonus: you won't have to google how to write a for loop in bash ever again (which I, writing them rarely, and them being unintuitive enough, had to do every single time)!
- shmerl 3y ago
  Tip for some easy to remember Bash loop constructs: Incremental index: for ((i = 0; i < 10; i++)); do echo $i; done For iterating over an array: foo[0]=a foo[1]=b for i in ${foo[@]}; do echo $i; done
  - cube2222 3y ago
    Just to illustrate for others, in fish that would be for i in (seq 10); echo $i; end or usually written as for i in (seq 10) echo $i end and that is already based on iteration, so for iterating over files, you'll similarly use for f in (ls); echo $f; end and it works the same for arrays.
    - user982 3y ago
      Your example in fish: for i in (seq 10); echo $i; end directly translated to bash: for i in $(seq 10); do echo $i; done
      - bravetraveler 3y ago
        No need for seq :) for i in {1..10}; do echo $i ; done If, for whatever reason, you want leading zeroes - BASH will respect that. Do {01..10}
    - shmerl 3y ago
frankjr 3y ago
More on the motivation behind the rewrite. https://github.com/fish-shell/fish-shell/pull/9512#issuecomment-1410820102 https://github.com/fish-shell/fish-shell/pull/9512#issuecomm...
- silverlyra 3y ago
  Wow, thank you for posting this. I’ve been kinda curious to try Fish over the years, but seeing this message from one of the maintainers – how mature and well-reasoned, how both charmingly joking and firmly assertive it is – now really gets me thinking that I’ve been missing out on using an excellent project.
  - acdha 3y ago
    I used bash heavily for years but decided I’d spent enough time maintaining dotfiles & working around quirks around the middle of the last decade. I looked at a few alternatives but since fish had everything I wanted builtin, I decided to try it for a while. After the first day, I decided the experiment was over and switched everywhere. It’s great software both for how much it does and how little it forces you to think about how it works as opposed to what you’re trying to do.
- noobermin 3y ago
  It is kind of telling that they thought porting to c++17 is "too much of a hassle" but rewriting everything in a new language isn't! Sorry, you're never ever going to beat "we did it to chase the new shiny" which is the story across the dev world. That said, I don't use fish and wish them the best
  - coldtea 3y ago
    >It is kind of telling that they thought porting to c++17 is "too much of a hassle" but rewriting everything in a new language isn't! "Too much of a hassle" can mean "too much of a hassle in absolute terms" or "Too much of a hassle compared to what you gain". And porting to c++17 is probably high on the latter...
3PS 3y ago
As someone who daily drives fish on ~4 different operating systems and loves it, I've been really excited about this rewrite and blown away by how fast it's been progressing given the size and complexity of the codebase. It will also somewhat lower the barrier to contributing for a lot of people, including myself. Another thing I'm very excited about, which has received less attention, is the planned future fish rewrite to use UTF-8 instead of wchar_t (typically UTF-16). UCS2 and UTF-16 have been a plague on software and fortunately Rust makes working with UTF-8 a breeze.
- cpeterso 3y ago
  > wchar_t (typically UTF-16) Complicating supporting multiple compilers in one code base, sizeof(wchar_t) is 2 bytes in MSVC (UTF-16) and 4 bytes in gcc (UTF-32).
  - ordu 3y ago
    MSVC isn't used on Unix, is it? It is probably not a concern for them, because they do not support Windows anyway.
    - cpeterso 3y ago
      True, AFAIK, but plenty of cross-platform software supports MSVC for compiling on Windows and clang and gcc for other platforms.
    - kryptiskt 3y ago
      It's 16 bits on mingw GCC on windows, as that also uses the Microsoft libc. I hesitate to say that it's UTF-16 as it's entirely up to the app to use the type properly.
esafak 3y ago
Why, was the C++ codebase becoming unmanageable?
- theshrike79 3y ago
  Comment by the creator: https://github.com/fish-shell/fish-shell/pull/9512#issuecomment-1410820102 https://github.com/fish-shell/fish-shell/pull/9512#issuecomm... tl;dr - string handling - threading - cmake issues
- darthrupert 3y ago
  Becoming?
  - DoctorDabadedoo 3y ago
    I was raised in C++ spaguetti code bases, I didn't see a loved and well groomed project until I became a man.
paradox460 3y ago
Fish is such an underrated shell. They make some very strong, opinionated choices (like ditching POSIX compatibility), and the end result is an extremely nice shell. I've been using it for a bit over a decade now, and still love it. Fish shell scripting is also extremely pleasant to write, it feels like an ergonomic bash. There are a few warts, as with any project, but none of them have ever actually ever blocked me from just getting what I wanted done.
thowaway91234 3y ago
I love fish. Switch from ZSH+Prezto to just plain Fish and I'm not missing anything and it's way faster. All the servers have bash and I still write bash scripts, but for day-to-day terminal stuff it's Fish all the way for me.
asylteltine 3y ago
I’m glad rust is replacing legacy languages like C and C++. It’s time to stop using memory unsafe language ffs!
exxos 3y ago
So, what new features do we get from that? Except that it doesn't work on Windows any more?
- jenadine 3y ago
  Never worked on Windows. The programming language has nothing to do with that anyway.
  - exxos 3y ago
    It does. With Go, it would have worked out of the box on all the targets Go can support.
    - Cu3PO42 3y ago
      > It does. It works in Cygwin right now, it doesn't work on Win32 without a compatibility layer. Personally, I don't think of that as "working on Windows", but I concede that that's somewhat up to interpretation on the "on Windows" part. I'm confident that someone is going to get a MingW build working even if it's not official. > With Go, it would have worked out of the box on all the targets Go can support. That's absolutely disingenious. If you choose to only use the Go standard library , sure. But the same is true for Rust and even for C++. If you don't use any platform-specific APIs most languages will work on any target. Fish, however, does use platform-specific APIs and nothing about Go changes that.
    - dymk 3y ago
      unless you have to deal with OS specific APIs around process management and tty input, which is the bulk of what makes a shell challenging to implement
    - Volundr 3y ago
      As long as you called no platform specific APIs. The same is true of Rust and many (even most) languages. Go isn't magic here.
  - speed_spread 3y ago
ianschmitz 3y ago
As someone who uses zsh + spaceship, what benefits would I gain moving to fish as my main shell? I don’t write many bash scripts so the scripting side is less of a concern.
- jquaint 3y ago
  I like use fish + starship.rs. Which gives a pretty similar experience. Starship can actually share you prompt across different shells so I get the same experience in zsh and fish. I find I stick to fish more because: 1. has more features that I like out of the box. zsh requires oh-my-zsh to get similar features and that's just another thing for me to install every time. 2. Help menu tab completion. Fish has many completions for common shell apps that will display descriptions from the help menu from just hitting tab. 3. Scripting is much better, while you might not use it much now it much now you don't have a hard corner to cut yourself on if you do need it at some point.
- DoctorDabadedoo 3y ago
  Tbh, little, mostly convenience (best metaphor I can give is installing Sublime Text vs manually installing your vim and your own personal configs). By default it supports a bunch of interesting things, autocomplete, iteractive filesystem navigation, theming (I used oh-my-fish in the past, not sure how it is now), etc. I like it, I would love to run it as my main shell, but I just do too much scripting for my own good to hop on this wagon.
- tipsytoad 3y ago
  Eh, you can probably get very similar to fish with zsh + loads of plugins, but fish has lots of niceties out of the box (syntax highlighting, autosuggestion based on your directory). I've been using fish + starship with just a fzf plugin and it's got everything I need. Check it out, it's effective with very little config
  - flexagoon 3y ago
    Speaking of starship, today I realized that I don't really need any of its features, I just like the way it looks. So I replicated it with pure fish by creating a simple function: function fish_prompt # Fedora Silverblue workaround set -l pwd (string replace /var/home /home $PWD) echo echo -s (set_color -o cyan)(prompt_pwd -D 3 $pwd) (set_color magenta)(fish_vcs_prompt) echo -ns (set_color green) "" (set_color normal) " " end
deleted 3y ago
[deleted]
chrysoprace 3y ago
I've always been curious about Fish, but was turned off by it not being POSIX-compliant. Is there anybody who can share their experiences with issues and workarounds in this area?
- hiepph 3y ago
  > Is there anybody who can share their experiences with issues and workarounds in this area? Just use your Bash/zsh to run Bash/zsh scripts: `bash script.sh`. > turned off by it not being POSIX-compliant. I was like this when I first started using Fish. I spent some time to learn some different syntax to get away from the POSIX-compliance. Overall, I think the saner syntax of Fish is worth the effort. Now I use the terminal much happier. Besides, 90% of the time I don't need to follow POSIX-compliant. Many scripts or extensions nowadays support Fish. For enterprise use, I still stick to Bash/zsh. They're the standard.
- 22c 3y ago
  POSIX compliance is practically a non-issue for fish as it's not intended to be a replacement for bash/shell scripts. It's intended to be an interactive shell (eg. your daily driver) and to that end, it's quite good. The downside of this is that you do need to "context switch" a little, especially if you've been using bash/zsh for most of your life. I find it easy to differentiate between when I am using the shell as a user interface and when I'm using bash/sh as an interpreter, but for others that might not be as intuitive. I've also found that since I've stopped using POSIX compliant shells as my daily driver, I tend to "promote" my scripts to a more general purpose language much sooner than I used to when nearly everything could be done in bash.
_lvbh 3y ago
Been using fish for a year. Although I don’t like how they break compatibility with standards so that some scripts don’t work (gvm, nvm, etc), it has all the features I would usually set up manually with zsh. After trying to configure zsh a few different machines, I gave up and went for default fish on all of them. It’s already working so well, not sure what there is to gain by porting to Rust. Security? If something can maliciously tamper with fish, it’s probably already on your system or am I missing something?
- paradox460 3y ago
  They have a variety of reasons to move to rust, as outlined in their original rust discussion[1]. Mostly around finding other contributors, and adding an async/parallel mode they're comfortable with. [1] https://github.com/fish-shell/fish-shell/pull/9512 https://github.com/fish-shell/fish-shell/pull/9512
ochronus 3y ago
Oh! I missed this, what's the original reason for doing the move? Any insight on this?
- ochronus 3y ago
  Hm, why the downvote? I'm genuinely interested.
  - Vorh 3y ago
    Presumably because the second to top comment links this issue, which answers your question: https://github.com/fish-shell/fish-shell/pull/9512#issuecomment-1410820102 https://github.com/fish-shell/fish-shell/pull/9512#issuecomm...
    - ochronus 3y ago
      Thanks!

335 points by rhim 3y ago

one of the fastest shells out there will probably get even faster. ever since I switched from zsh to fish, my terminal productivity has gone up a lot.

bayindirh 3y ago
I don't think C++ and Rust has that big of a performance difference. They are probably neck to neck with no clear winner.
- LoganDark 3y ago
  The real difference is in compile-time abstractions. It's much easier to organize things in Rust, especially with a borrow checker. You can confidently remove overhead while being sure that it'll continue to be memory safe.
  - bayindirh 3y ago
    With some strong design decisions, and with modern C++ facilities, you can make sure that your code never does funny things in C++, too. Yes, Rust's BC is a great technology, but C++ is not a runaway nuclear fire which contaminates and melts everything around it when it comes to sanity and security. Yes, Rust allows you to run amok by not allowing it, but you can design a good foundation to your code which prevents tons of problems out of the gate in C++, and this is without using smart-pointers and other things available to you.
    - pdpi 3y ago
      > but you can design a good foundation to your code which prevents tons of problems out of the gate in C++, And there is an almost perfect overlap between the people capable of pulling off a rewrite like this and the people who would write a good C++ foundation in the first place.
    - LoganDark 3y ago
      > Yes, Rust's BC is a great technology, but C++ is not a runaway nuclear fire which contaminates and melts everything around it when it comes to sanity and security. I never meant to imply such a thing. However, Rust is simply a much better-defined language. Moves do what you expect, smart pointers work like you'd expect, there are not 3 (or 5) different types of constructors you have to understand and implement properly if you want to build your own abstractions. You don't have to remember where to put std::move, you don't have to remember what happens to the variable after you move out of it, you don't have to use the awful variant accessor functions if you want a tagged union and so on. Yes, you can do all this in C++. You can build safe abstractions. You can build layers on top of the STL to make it less awful. You can make use of modules and #embed and other nice new features that C++ is getting. But you need to be a lot more careful compared to Rust, because the compiler is not going to help you.
    - Matumio 3y ago
      > C++ is not a runaway nuclear fire which contaminates and melts everything around it when it comes to sanity and security. Not sanity, maybe. But security? How much more would it take to declare a nuclear meltdown: https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...
- joshlk 3y ago
  In Rust it’s easier to leverage external crates/libraries that are more optimised than rolling your own. This can lead to performance increases (I don’t know if fish is doing this)
  - starcraft2wol 3y ago
    C programs without libraries tend to be really fast for the opposite reason. So this isn’t persuasive even though it seems like it should be true
    - acdha 3y ago
      This is only true for very simple single-threaded code. Once you’re doing anything the compiler can’t trivially optimize, you’re using libraries, getting left far behind by the Rust program, or both.
      - starcraft2wol 3y ago
        Since most industrial software is in C and C++ an example would be more convincing. > doing anything the compiler can’t trivially optimize What does compiler optimization have to do with libraries? > single threaded Plenty of C and C++ programs are multi threading using a system api like pthreads.
        acdha 3y ago
        > Since most industrial software is in C and C++ an example would be more convincing. Agreed- do you have any to back up your original claim? > > doing anything the compiler can’t trivially optimize > What does compiler optimization have to do with libraries? One of the most common reasons to use a library is because it has optimizations you want to use. For example, performance-sensitive programs link against OpenSSL even if they’re just using a couple of hash functions because the SHA-256 function you copied into your codebase won’t have their assembly backend or use of processor intrinsics. Repeat for string searches, pattern matching, all kinds of math, etc. where people have written libraries with pricessor-specific assembly, SIMD intrinsics, etc. > Plenty of C and C++ programs are multi threading using a system api like pthreads. Yes - and the long history of bugs related to that is why many stayed single-threaded because it was more work than the author had time for to make the code thread-safe. Rust’s “fearless concurrency” talk isn’t just marketing but a reaction by people with a lot of experience in the area realizing just how much more they used concurrency when it was easy to do correctly rather than infamously hard.
- andrewaylett 3y ago
  The advantages of Rust come when trying to do complex things with concurrency, and wanting to know that they're either going to be safe, or fail to compile. Consider the now-classic "Fearless Concurrency" post about Stylo: https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-In-Firefox-Quantum.html https://blog.rust-lang.org/2017/11/14/Fearless-Concurrency-I... Strictly, C++ pretty much has to be no slower than Rust. But it's certainly possible that a regular human might in practice write higher-performing parallel code when using Rust.
  - ordu 3y ago
    At the same time Rust forbids some practices pushing a coder to choose another path. To name a specific example, try to roll out your own dynamically sized type type or a self-referential one. Such small things could contribute to performance too.
    - andrewaylett 3y ago
      Yes, there are definitely things one may do in C++ that aren't possible in Rust. In the absence of bugs, I think you could pretty much recreate any Rust program in C++ and have it be just as fast. Of course, you can't assume the absence of bugs in real world software. The C++ version would lack any of the safety added by Rust's compile time checks.
nick__m 3y ago
I would not bet on this! from the link : We have no real idea what the performance of the finished port is going to be. Early results are encouraging, but it is entirely possible this will be ~20% slower in some cases.
- tubthumper8 3y ago
  This part also seems relevant: > Fish also uses threads, for things like the autosuggestion and syntax highlighting, and we would like to have more "threads"/"concurrency"/"run-thing-in-backgroundness" (please insert the correct term here, I have never been good at these things). One large project has been to run multiple fish builtins and functions "at the same time", to enable things like backgrounding functions (ideally without using "subshells" because those are an annoying environment boundary that shows up in surprising places in other shells), and to simply be able to pipe two builtins into each other and have them actually process both ends of the pipe "simultaneously". > C++ offers few guarantees on what can be accessed from which thread. @ridiculousfish has been trying to crack this for years, and hasn't been confident enough in his solution. We want a tech stack that helps us here, and C++ doesn't. The initial rewrite may be no faster, or possibly slower as stated, but long-term they'd be able to safely add more concurrency or parallelism that they weren't able to before.
  - nick__m 3y ago
    I completely agree like someone cleverer than me said : It is easier to make correct program faster than making a fast program correct!
fbdab103 3y ago
Is shell performance a limitation for some workflows? I naively think of it as some glue which shunts the work elsewhere. Maybe in the efficiency of pipe? I suppose those lunatics who write full programs in bash? I will always take faster code, but that seems like an odd bulletpoint to highlight given the many quality of life improvements fish has to offer.
- kstrauser 3y ago
  Kind of, yeah. When I used zsh, oh-my-zsh made the shell startup a lot slower, even though I wasn’t going crazy with the customizations. Opening a new terminal tab would take a couple seconds to get a prompt. My current fish setup is imperceptibly fast to start. Those little delays add friction. Not an intolerable amount, sure, but it’s there. While I switched to fish for other reasons, that alone would keep me from going back now.
  - lkbm 3y ago
    I once spent a while adding timings between each item in my zsh config files to find what was slowest. The nvm init was the worst of it, so now I have an alias for `$NVM_DIR/nvm.sh ] && \. "$NVM_DIR/nvm.sh" && \. $NVM_DIR/bash_completion` I just run manually before using nvm, rather than letting it slow me down half a second or whatever it was every time I open a new terminal. It's worth poking around if things get slow enough to be a pain. There's a decent chance it's 1-2 things that you don't even care about all that much.
    - paradox460 3y ago
      You might check out rtx[1] Its an asdf[2] rewrite, in rust, that can do most of the things nvm can [1] https://github.com/jdx/rtx https://github.com/jdx/rtx [2] https://github.com/asdf-vm/asdf https://github.com/asdf-vm/asdf
    - dividedbyzero 3y ago
      fish actually has a built-in profiler for its startup that can be enabled via an argument: > --profile-startup=PROFILE_FILE > Will write timing for fish startup to specified file.
bch 3y ago
> one of the fastest shells out there will probably get even faster […] my terminal productivity has gone up a lot. Surely you’re not typing and managing jobs at a pace where C vs C++ vs Rust vs $lang matters… or I’m missing something about what fish is bringing to the table.
deleted 3y ago
[deleted]

cube2222 3y ago

1. It's amazing that they're doing this as a gradual C++ to Rust rewrite, while keeping it working end-to-end, if I understand correctly. 2. It's amazing how quickly this is going. 3. If you haven't tried fish yet, make sure to do so! It's a really ergonomic shell and overall very pleasant to use, with good defaults (you don't have to customize it, even though you can, for a great experience). I've switched from bash a couple years ago and haven't looked back since. Bonus: you won't have to google how to write a for loop in bash ever again (which I, writing them rarely, and them being unintuitive enough, had to do every single time)!

shmerl 3y ago
Tip for some easy to remember Bash loop constructs: Incremental index: for ((i = 0; i < 10; i++)); do echo $i; done For iterating over an array: foo[0]=a foo[1]=b for i in ${foo[@]}; do echo $i; done
- cube2222 3y ago
  Just to illustrate for others, in fish that would be for i in (seq 10); echo $i; end or usually written as for i in (seq 10) echo $i end and that is already based on iteration, so for iterating over files, you'll similarly use for f in (ls); echo $f; end and it works the same for arrays.
  - user982 3y ago
    Your example in fish: for i in (seq 10); echo $i; end directly translated to bash: for i in $(seq 10); do echo $i; done
    - bravetraveler 3y ago
      No need for seq :) for i in {1..10}; do echo $i ; done If, for whatever reason, you want leading zeroes - BASH will respect that. Do {01..10}
  - shmerl 3y ago

frankjr 3y ago

More on the motivation behind the rewrite. https://github.com/fish-shell/fish-shell/pull/9512#issuecomment-1410820102 https://github.com/fish-shell/fish-shell/pull/9512#issuecomm...

silverlyra 3y ago
Wow, thank you for posting this. I’ve been kinda curious to try Fish over the years, but seeing this message from one of the maintainers – how mature and well-reasoned, how both charmingly joking and firmly assertive it is – now really gets me thinking that I’ve been missing out on using an excellent project.
- acdha 3y ago
  I used bash heavily for years but decided I’d spent enough time maintaining dotfiles & working around quirks around the middle of the last decade. I looked at a few alternatives but since fish had everything I wanted builtin, I decided to try it for a while. After the first day, I decided the experiment was over and switched everywhere. It’s great software both for how much it does and how little it forces you to think about how it works as opposed to what you’re trying to do.
noobermin 3y ago
It is kind of telling that they thought porting to c++17 is "too much of a hassle" but rewriting everything in a new language isn't! Sorry, you're never ever going to beat "we did it to chase the new shiny" which is the story across the dev world. That said, I don't use fish and wish them the best
- coldtea 3y ago
  >It is kind of telling that they thought porting to c++17 is "too much of a hassle" but rewriting everything in a new language isn't! "Too much of a hassle" can mean "too much of a hassle in absolute terms" or "Too much of a hassle compared to what you gain". And porting to c++17 is probably high on the latter...

3PS 3y ago

As someone who daily drives fish on ~4 different operating systems and loves it, I've been really excited about this rewrite and blown away by how fast it's been progressing given the size and complexity of the codebase. It will also somewhat lower the barrier to contributing for a lot of people, including myself. Another thing I'm very excited about, which has received less attention, is the planned future fish rewrite to use UTF-8 instead of wchar_t (typically UTF-16). UCS2 and UTF-16 have been a plague on software and fortunately Rust makes working with UTF-8 a breeze.

cpeterso 3y ago
> wchar_t (typically UTF-16) Complicating supporting multiple compilers in one code base, sizeof(wchar_t) is 2 bytes in MSVC (UTF-16) and 4 bytes in gcc (UTF-32).
- ordu 3y ago
  MSVC isn't used on Unix, is it? It is probably not a concern for them, because they do not support Windows anyway.
  - cpeterso 3y ago
    True, AFAIK, but plenty of cross-platform software supports MSVC for compiling on Windows and clang and gcc for other platforms.
  - kryptiskt 3y ago
    It's 16 bits on mingw GCC on windows, as that also uses the Microsoft libc. I hesitate to say that it's UTF-16 as it's entirely up to the app to use the type properly.

esafak 3y ago

Why, was the C++ codebase becoming unmanageable?

theshrike79 3y ago
Comment by the creator: https://github.com/fish-shell/fish-shell/pull/9512#issuecomment-1410820102 https://github.com/fish-shell/fish-shell/pull/9512#issuecomm... tl;dr - string handling - threading - cmake issues
darthrupert 3y ago
Becoming?
- DoctorDabadedoo 3y ago
  I was raised in C++ spaguetti code bases, I didn't see a loved and well groomed project until I became a man.

paradox460 3y ago

Fish is such an underrated shell. They make some very strong, opinionated choices (like ditching POSIX compatibility), and the end result is an extremely nice shell. I've been using it for a bit over a decade now, and still love it. Fish shell scripting is also extremely pleasant to write, it feels like an ergonomic bash. There are a few warts, as with any project, but none of them have ever actually ever blocked me from just getting what I wanted done.

thowaway91234 3y ago

I love fish. Switch from ZSH+Prezto to just plain Fish and I'm not missing anything and it's way faster. All the servers have bash and I still write bash scripts, but for day-to-day terminal stuff it's Fish all the way for me.

asylteltine 3y ago

I’m glad rust is replacing legacy languages like C and C++. It’s time to stop using memory unsafe language ffs!

exxos 3y ago

So, what new features do we get from that? Except that it doesn't work on Windows any more?

jenadine 3y ago
Never worked on Windows. The programming language has nothing to do with that anyway.
- exxos 3y ago
  It does. With Go, it would have worked out of the box on all the targets Go can support.
  - Cu3PO42 3y ago
    > It does. It works in Cygwin right now, it doesn't work on Win32 without a compatibility layer. Personally, I don't think of that as "working on Windows", but I concede that that's somewhat up to interpretation on the "on Windows" part. I'm confident that someone is going to get a MingW build working even if it's not official. > With Go, it would have worked out of the box on all the targets Go can support. That's absolutely disingenious. If you choose to only use the Go standard library , sure. But the same is true for Rust and even for C++. If you don't use any platform-specific APIs most languages will work on any target. Fish, however, does use platform-specific APIs and nothing about Go changes that.
  - dymk 3y ago
    unless you have to deal with OS specific APIs around process management and tty input, which is the bulk of what makes a shell challenging to implement
  - Volundr 3y ago
    As long as you called no platform specific APIs. The same is true of Rust and many (even most) languages. Go isn't magic here.
- speed_spread 3y ago

ianschmitz 3y ago

As someone who uses zsh + spaceship, what benefits would I gain moving to fish as my main shell? I don’t write many bash scripts so the scripting side is less of a concern.

jquaint 3y ago
I like use fish + starship.rs. Which gives a pretty similar experience. Starship can actually share you prompt across different shells so I get the same experience in zsh and fish. I find I stick to fish more because: 1. has more features that I like out of the box. zsh requires oh-my-zsh to get similar features and that's just another thing for me to install every time. 2. Help menu tab completion. Fish has many completions for common shell apps that will display descriptions from the help menu from just hitting tab. 3. Scripting is much better, while you might not use it much now it much now you don't have a hard corner to cut yourself on if you do need it at some point.
DoctorDabadedoo 3y ago
Tbh, little, mostly convenience (best metaphor I can give is installing Sublime Text vs manually installing your vim and your own personal configs). By default it supports a bunch of interesting things, autocomplete, iteractive filesystem navigation, theming (I used oh-my-fish in the past, not sure how it is now), etc. I like it, I would love to run it as my main shell, but I just do too much scripting for my own good to hop on this wagon.
tipsytoad 3y ago
Eh, you can probably get very similar to fish with zsh + loads of plugins, but fish has lots of niceties out of the box (syntax highlighting, autosuggestion based on your directory). I've been using fish + starship with just a fzf plugin and it's got everything I need. Check it out, it's effective with very little config
- flexagoon 3y ago
  Speaking of starship, today I realized that I don't really need any of its features, I just like the way it looks. So I replicated it with pure fish by creating a simple function: function fish_prompt # Fedora Silverblue workaround set -l pwd (string replace /var/home /home $PWD) echo echo -s (set_color -o cyan)(prompt_pwd -D 3 $pwd) (set_color magenta)(fish_vcs_prompt) echo -ns (set_color green) "" (set_color normal) " " end

deleted 3y ago

[deleted]

chrysoprace 3y ago

I've always been curious about Fish, but was turned off by it not being POSIX-compliant. Is there anybody who can share their experiences with issues and workarounds in this area?

hiepph 3y ago
> Is there anybody who can share their experiences with issues and workarounds in this area? Just use your Bash/zsh to run Bash/zsh scripts: `bash script.sh`. > turned off by it not being POSIX-compliant. I was like this when I first started using Fish. I spent some time to learn some different syntax to get away from the POSIX-compliance. Overall, I think the saner syntax of Fish is worth the effort. Now I use the terminal much happier. Besides, 90% of the time I don't need to follow POSIX-compliant. Many scripts or extensions nowadays support Fish. For enterprise use, I still stick to Bash/zsh. They're the standard.
22c 3y ago
POSIX compliance is practically a non-issue for fish as it's not intended to be a replacement for bash/shell scripts. It's intended to be an interactive shell (eg. your daily driver) and to that end, it's quite good. The downside of this is that you do need to "context switch" a little, especially if you've been using bash/zsh for most of your life. I find it easy to differentiate between when I am using the shell as a user interface and when I'm using bash/sh as an interpreter, but for others that might not be as intuitive. I've also found that since I've stopped using POSIX compliant shells as my daily driver, I tend to "promote" my scripts to a more general purpose language much sooner than I used to when nearly everything could be done in bash.

_lvbh 3y ago

Been using fish for a year. Although I don’t like how they break compatibility with standards so that some scripts don’t work (gvm, nvm, etc), it has all the features I would usually set up manually with zsh. After trying to configure zsh a few different machines, I gave up and went for default fish on all of them. It’s already working so well, not sure what there is to gain by porting to Rust. Security? If something can maliciously tamper with fish, it’s probably already on your system or am I missing something?

paradox460 3y ago
They have a variety of reasons to move to rust, as outlined in their original rust discussion[1]. Mostly around finding other contributors, and adding an async/parallel mode they're comfortable with. [1] https://github.com/fish-shell/fish-shell/pull/9512 https://github.com/fish-shell/fish-shell/pull/9512

ochronus 3y ago

Oh! I missed this, what's the original reason for doing the move? Any insight on this?

ochronus 3y ago
Hm, why the downvote? I'm genuinely interested.
- Vorh 3y ago
  Presumably because the second to top comment links this issue, which answers your question: https://github.com/fish-shell/fish-shell/pull/9512#issuecomment-1410820102 https://github.com/fish-shell/fish-shell/pull/9512#issuecomm...
  - ochronus 3y ago
    Thanks!