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.
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...
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.
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.
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.
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)
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.
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!
In what way does fish being built with cargo affect you as (not even) a user? Were you fish-curious in that you were interested in becoming a contributor? Or do you make a habit of judging projects that you might be interested in using based primarily on their build system?
The same reason you might care about the artist or producer of a song: its context generally implies certain characteristics you might associate and appreciate.
For example, most Rust projects use clap which provides really nice command line help menus and also have relatively good performance in general.
What does it matter which tool-chain they use .
I can understand if the difference is it made it notably slower or they dropped some features because they couldn't get it done in rust . But purely as an end user why would it matter if it's written in rust or cpp ?
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
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.
well that's the thing, you never know. certainly if i ever used rust to a serious degree, i'd not stop using darcs. however right now that'd necessitate bypassing the whole package management part of cargo, at least for my own libraries (and i suffer from a terminal case of NIH syndrome)
i don't think it's reasonable to assert that my own quirks and tastes are explicitly tended to. and that's why ideally you just give the programmer space to do whatever, hence why it's so hard. vcs is just one single point of contention. this isn't unique to rust by the way. cargo is arguably a bit better than the dune experience, it's a bit more flexible and feels simpler.
arguably system package managers are better here, since they're effectively opt-in by choosing what distribution of what operating system you use. language package managers don't have that luxury.
sure sure, and what i mean is that ideally the package manager can be made to use any arbitrary vcs system by the programmer. that's all. early on choices were made with cargo's development to where it's non-trivial to make something like that work, you touched on that briefly. it's a good example of why making a package manager is hard, there are so many aspects to them and it's really easy to engineer yourself into a corner to where any individual aspect of them might be flawed. typical software problem, expounded by the fact that package managers are deceptively complicated. doubly expounded by what i mention with language package managers not having the "opt-in" inherent quality of system package managers, not in the same way.
ideally it'd just have an interface you can write a module against. maybe they've added that? i sure hope they didn't have to hardcode the options of that new vcs switch ;)
> that’s why rustc and cargo are different
indeed. but rust analyzer really likes you to use cargo. i know it provides facilities for specifying a json in place of cargo.toml, which is great, but my limited experience with that saw me running into some weird issues (maybe they've been fixed, maybe it was just a skill issue.)
also i will say cargo does at least let you specify local paths as dependencies relatively painlessly, so it gets points for that escape hatch.
> (maybe they've been fixed, maybe it was just a skill issue.)
Maybe! This is how Meta uses RA, and they sponsor development, and I know at least one of the people working on it and he really cares about getting things right, so if you run into it again, you should open up an issue.
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.
[1] https://github.com/fish-shell/fish-shell/pull/9512