I had this immediate assumption that this was implemented in Rust when I saw the landing page. Didn't know for sure until I checked Github, but lo and behold it was which I think is funny. I sense a trend where new and interesting projects are usually implemented in Rust.
I used to use `skim` a fair amount, but over time I've gradually found myself defaulting to `fzf`, but YMMV. I haven't personally used `exa`, but I do like `lsd`. I would also vouch for the other three tools mentioned by eerrt (`ripgrep`, `fd`, and `bat`).
Was reading and thinking "oh boy this looks so good, I wish it was written in Rust..." and then reached the "Installation Instructions" just to see "cargo install broot". HERE WE GO
> Was reading and thinking "oh boy this looks so good, I wish it was written in Rust..."
Can I ask... why?
What is the difference between a program that makes you feel "oh boy this looks so good" written is some XY language, and the same program with the same functionality written in Rust?
When I saw the landing page, I reckoned it looked good, and then I thought these very words to myself as I went to the installation page: “ah, but is it written in Rust?” Because if it is, then I know I can install it both quickly and easily, and expect it to run fast as well. Command line tools written in Perl, Python, Node, JavaScript are always more effort to get going, and much more effort if you’re (a) using Windows, or (b) unwilling to pollute /usr or equivalent with things that won’t be managed by the OS’s package manager.
Every non-standard tool that you get in the habit of using is another piece of friction when switching machines or using a machine not configured as your own, where you may not even be able to install things. With Rust, I know I’ll be able to get it going easily, regardless of whether it’s in some OS-level package manager: it’ll be a single binary that I can just drop into my personal bin directory, and it’ll just work.
Seriously, the deployment story is just so good for languages that compile into a single statically-linked binary, when compared with dynamic languages.
So my threshold for “will I bother trying this non-standard tool out?” tends to be much lower for something written in Rust. I have several Rust utilities that I take the trouble of installing, and now only one non-Rust utility that I use in this fashion, git-revise (Python, and git-rebase is generally a tolerable alternative if I can’t set git-revise up).
Well then, back to my narrative. I wasn’t actually expecting it to be in Rust (though on reflection, why not?), but when I saw “cargo install broot”, I cackled aloud.
I think it's a brain shortcut from "Oh nice, this thing won't startup a VM that fill my RAM and peg my CPU". Would you run `ls -l` if it were written in Java or Javascript ?
Maybe they are one of those people that can't help but comment that things should be rewritten in rust, but is also aware that doing so is annoying. Someone like that might want software to be already written in rust so they don't have to annoy anyone.
Is cargo known for build problems? I've never used it before now and I took a shot in the dark with `sudo apt install cargo`, then `cargo install broot` went off without a hitch. I just had to add ~/.cargo/bin to PATH and I was good to go. This was in WSL no less.
Is this experience atypical? I've actually been running through the getting started guide for rust-lang as it left a positive impression on me. Something like this in C land seems unachievable.
