5 ms·

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]

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]