5 ms·

The most interesting thing about Fish 4.0.0 for most people will be that it is now written in Rust, which they talk about here [1]. Looking forward to testing i

by abound 2y ago

The most interesting thing about Fish 4.0.0 for most people will be that it is now written in Rust, which they talk about here [1]. Looking forward to testing it out and seeing if there are any noticeable differences. [1] https://github.com/fish-shell/fish-shell/pull/9512 https://github.com/fish-shell/fish-shell/pull/9512

markstos 2y ago
I'll be curious if it's faster.
- robin_reala 2y ago
  It’s broadly the same speed currently, but the goal was always to do a simple port to start with, then iterate from there.
- darthrupert 2y ago
  Faster than previous C++? Only if there were actual performance bugs that they fixed while doing the port.
  - rootnod3 2y ago
    What makes you think so? The Rust compiler is able to instrument LLVM a lot better and provide it with a lot more info than C++ can. The borrow checker does a lot of the work there to for example keep things on the stack or do LSE or GSE and other optimizations. It isn't just about "oh, the rewrite allowed them to restructure things and optimize the algos". It is also that Rust due to its nature is able to be absolutely damn fucking sure that it can remove or optimize certain parts, whereas C++ can't in many cases.
    - steveklabnik 2y ago
      Additionally, some people shared that they feel more comfortable making more aggressive optimizations in their Rust code because the borrow checker has their back. Stylo was tried twice in C++ before the Rust attempt, and it never worked out, because the threading was too hard to get right. In theory you could have done it. But in theory, theory and practice are the same, but in practice, they’re different.
      - vanderZwan 2y ago
        IIRC, you yourself commented a few years ago in a thread on HN that the Rust situation was still a lot like "because of certain guarantees Rust makes we should be able to perform tons of optimizations that C++ could never do, and we haven't even gotten around to implementing most of them yet", has that situation improved a lot since? ("a few" might be off by pre-pandemic amount of years, my memory is a bit fuzzy there)
        steveklabnik 2y ago
        I vaguely remember that :) It's progressed in the sense of like, the Unsafe Code Guidelines and opsem teams are hammering down the exact semantics still, and have made a lot of progress. I'm not aware of any actual optimization work taking place off of it yet, which would make sense given that it's not all fully hammered out yet. I also might have been handwaving towards how restrict kept having to be turned off because it was broken, meaning very few C or C++ codebases seem to use it at all, whereas virtually every Rust reference has it on. It's been back on for a while now.
        vanderZwan 2y ago
        Yeah I forgot the exact context of the quote too, no worries :). EDIT: it probably had something to do with aliasing and alignment (because when aren't people sighing about C/C++ when it comes to that topic?) Thank for the general update! I might not write any Rust code myself, but I do enjoy quite a few programs written in it, so I was hoping to hear there was more progress for the sake of the developers behind those programs. But I can also imagine that these kind of things take time to figure out properly, to avoid repeating mistakes of previous languages (and that's before we even get to the task of implementing anything). Wish the people working on these issues all the best, and looking forward (from the sidelines) to what eventually comes out of it!
      - rootnod3 2y ago
        Oh definitely. Refactoring in Rust is a lot safer. Sometimes a lot more cumbersome, but definitely safer. Sometimes a refactor introduces a lifetime to a structure and now a loooot of places need changing, but at least it's safer. In C++, it would be less safe, but I could compile it and test the part I am trying to change or test first. It's a pro and con on either side. But for the end product, I err on the safety side for sure.
    - deleted 2y ago
      [deleted]
- bjoli 2y ago
  Anecdote time: I did a test like this with a small hobby project of mine (c++). I ported it to rust and saw roughly a 25% speed increase because of some refactorings I was meaning to do for a long time. I then ported the rust code back to c++ and saw another 15% gain in performance. Backporting the changes to rust again yielded no significant difference. I am no rust programmer though, and I don't think the rust code was very idiomatic. But then again I apparently write c++ like a common lisp programmer...
enriquto 2y ago
[flagged]
- benrutter 2y ago
  What do you dislike about it?
  - enriquto 2y ago
    quadratic dependency encouragement
  - xigoi 2y ago
    It encourages adding hundreds of dependencies to every project, taking up gigabytes of storage, making compilation slow and resulting in bloated binaries with potential vulnerabilities.
  - johnnyjeans 2y ago
    the only vcs it supports is git
    - steveklabnik 2y ago
      The —-vcs flag to cargo new supports git, hg, pijul, and fossil. It’s true that dependencies from a repository only supports git right now. Part of the issue there is just like, the VCS integration wasn’t don’t in a principled way (it happens!) and so it’s not simple. See here for more: https://github.com/rust-lang/cargo/issues/12102 https://github.com/rust-lang/cargo/issues/12102
      - johnnyjeans 2y ago
        no darcs? and this is why i really loathe language package managers, because they're prone to this kind of thing. assuming one has no problems with the opinions made in a language itself, when it has a tightly bound package manager embedded into it's ecosystem (using rust without cargo is like pulling teeth) you have an entire extra hurdle of far more rigid and controversial opinions to deal with. package managers are maybe next to shells with "it's several orders of magnitude harder to make a good one than it is to write a compiler." with the dozens, possibly hundreds of package managers i've touched over the years, there's only been one that i'd call "good". the absolute worst ones have always been language package managers. at this point i've basically written off the concept, even system package managers.

by abound 2y ago

markstos 2y ago

I'll be curious if it's faster.

robin_reala 2y ago
It’s broadly the same speed currently, but the goal was always to do a simple port to start with, then iterate from there.
darthrupert 2y ago
Faster than previous C++? Only if there were actual performance bugs that they fixed while doing the port.
- rootnod3 2y ago
  What makes you think so? The Rust compiler is able to instrument LLVM a lot better and provide it with a lot more info than C++ can. The borrow checker does a lot of the work there to for example keep things on the stack or do LSE or GSE and other optimizations. It isn't just about "oh, the rewrite allowed them to restructure things and optimize the algos". It is also that Rust due to its nature is able to be absolutely damn fucking sure that it can remove or optimize certain parts, whereas C++ can't in many cases.
  - steveklabnik 2y ago
    Additionally, some people shared that they feel more comfortable making more aggressive optimizations in their Rust code because the borrow checker has their back. Stylo was tried twice in C++ before the Rust attempt, and it never worked out, because the threading was too hard to get right. In theory you could have done it. But in theory, theory and practice are the same, but in practice, they’re different.
    - vanderZwan 2y ago
      IIRC, you yourself commented a few years ago in a thread on HN that the Rust situation was still a lot like "because of certain guarantees Rust makes we should be able to perform tons of optimizations that C++ could never do, and we haven't even gotten around to implementing most of them yet", has that situation improved a lot since? ("a few" might be off by pre-pandemic amount of years, my memory is a bit fuzzy there)
      - steveklabnik 2y ago
        I vaguely remember that :) It's progressed in the sense of like, the Unsafe Code Guidelines and opsem teams are hammering down the exact semantics still, and have made a lot of progress. I'm not aware of any actual optimization work taking place off of it yet, which would make sense given that it's not all fully hammered out yet. I also might have been handwaving towards how restrict kept having to be turned off because it was broken, meaning very few C or C++ codebases seem to use it at all, whereas virtually every Rust reference has it on. It's been back on for a while now.
        vanderZwan 2y ago
        Yeah I forgot the exact context of the quote too, no worries :). EDIT: it probably had something to do with aliasing and alignment (because when aren't people sighing about C/C++ when it comes to that topic?) Thank for the general update! I might not write any Rust code myself, but I do enjoy quite a few programs written in it, so I was hoping to hear there was more progress for the sake of the developers behind those programs. But I can also imagine that these kind of things take time to figure out properly, to avoid repeating mistakes of previous languages (and that's before we even get to the task of implementing anything). Wish the people working on these issues all the best, and looking forward (from the sidelines) to what eventually comes out of it!
    - rootnod3 2y ago
      Oh definitely. Refactoring in Rust is a lot safer. Sometimes a lot more cumbersome, but definitely safer. Sometimes a refactor introduces a lifetime to a structure and now a loooot of places need changing, but at least it's safer. In C++, it would be less safe, but I could compile it and test the part I am trying to change or test first. It's a pro and con on either side. But for the end product, I err on the safety side for sure.
  - deleted 2y ago
    [deleted]
bjoli 2y ago
Anecdote time: I did a test like this with a small hobby project of mine (c++). I ported it to rust and saw roughly a 25% speed increase because of some refactorings I was meaning to do for a long time. I then ported the rust code back to c++ and saw another 15% gain in performance. Backporting the changes to rust again yielded no significant difference. I am no rust programmer though, and I don't think the rust code was very idiomatic. But then again I apparently write c++ like a common lisp programmer...

enriquto 2y ago

[flagged]

benrutter 2y ago
What do you dislike about it?
- enriquto 2y ago
  quadratic dependency encouragement
- xigoi 2y ago
  It encourages adding hundreds of dependencies to every project, taking up gigabytes of storage, making compilation slow and resulting in bloated binaries with potential vulnerabilities.
- johnnyjeans 2y ago
  the only vcs it supports is git
  - steveklabnik 2y ago
    The —-vcs flag to cargo new supports git, hg, pijul, and fossil. It’s true that dependencies from a repository only supports git right now. Part of the issue there is just like, the VCS integration wasn’t don’t in a principled way (it happens!) and so it’s not simple. See here for more: https://github.com/rust-lang/cargo/issues/12102 https://github.com/rust-lang/cargo/issues/12102
    - johnnyjeans 2y ago
      no darcs? and this is why i really loathe language package managers, because they're prone to this kind of thing. assuming one has no problems with the opinions made in a language itself, when it has a tightly bound package manager embedded into it's ecosystem (using rust without cargo is like pulling teeth) you have an entire extra hurdle of far more rigid and controversial opinions to deal with. package managers are maybe next to shells with "it's several orders of magnitude harder to make a good one than it is to write a compiler." with the dozens, possibly hundreds of package managers i've touched over the years, there's only been one that i'd call "good". the absolute worst ones have always been language package managers. at this point i've basically written off the concept, even system package managers.