←back to thread

Introducing tmux-rs

(richardscollin.github.io)
857 points Jtsummers | 6 comments | 03 Jul 25 15:03 UTC | HN request time: 0.995s | source | bottom
Show context
mbreese ◴[03 Jul 25 15:19 UTC] No.44455951[source]▶
> You might be asking: why did you rewrite tmux in Rust? And yeah, I don’t really have a good reason. It’s a hobby project. Like gardening, but with more segfaults.

I love this attitude. We don’t necessarily need a reason to build new things. Who knows what will come out of a hobby project. Thanks to the author for the great write up!

Also, my gardening is full of segfaults, coding a new project is definitely safer to my yard.

replies(15): >>44456003 #>>44456205 #>>44456799 #>>44457023 #>>44457048 #>>44457108 #>>44457783 #>>44458165 #>>44458298 #>>44458461 #>>44459018 #>>44459396 #>>44459476 #>>44459885 #>>44463066 #
1. tombert ◴[03 Jul 25 17:04 UTC] No.44457108[source]▶
Completely agree. Not every project has to be out there to change the world.

I recently rewrote `fzf` [1] in Rust. Did I have any particular reason to do so? No, not really, regular `fzf` is fine, but I thought it would be a fun excuse to learn how fuzzy search algorithms work and how to exploit the channels in Rust. It was fun. There's no question that regular fzf is better but that wasn't the point, the point was to play with stuff and learn.

[1] https://github.com/Tombert/rs-fzf-clone

replies(1): >>44458722 #
2. carlmr ◴[03 Jul 25 20:07 UTC] No.44458722[source]▶
Nice, I do think fzf is a really good candidate for something that could be better if written in Rust. The fzy[1] C-rewrite is really fast, but I couldn't get it to give me as useful results when searching bash history.

[1] jhawthorn/fzy: :mag: A simple, fast fuzzy finder for the terminal https://share.google/TBp3pVaFngBTfaFyO

replies(3): >>44458823 #>>44462280 #>>44462406 #
3. tombert ◴[03 Jul 25 20:19 UTC] No.44458823[source]▶
Yeah, I think Rust makes some sense, and I do think I've done a few clever things like getting a linear-time "sort" by exploiting the fact that there's a discrete and finite number of "scores" [1], and avoiding copies by taking the indexed values and explicitly moving them into the source channel to avoid extra copies [2].

Someone smarter than me who is more familiar with TUI programming could almost certainly augment and improve what I wrote; I worked on it for as long as it was interesting to me. I use it for my home-built program launcher thing Sway, though most people would probably get better results with real fzf.

[1] https://github.com/Tombert/rs-fzf-clone/blob/main/src/helper... [2] https://github.com/Tombert/rs-fzf-clone/blob/main/src/proces...

4. ricardobeat ◴[04 Jul 25 08:04 UTC] No.44462280[source]▶
First time hearing anyone say fzf can be slow. I mostly use it for filtering relatively small lists (few K items), for example git reflogs, is speed an issue when searching the whole filesystem or something on these lines?

And assuming speed is not an issue, why would Rust make it better?

replies(1): >>44463432 #
5. milliams ◴[04 Jul 25 08:24 UTC] No.44462406[source]▶
Well there's been skim (https://github.com/skim-rs/skim) for a while as a fzf equivalent in Rust.
6. carlmr ◴[04 Jul 25 11:04 UTC] No.44463432{3}[source]▶
I didn't call it slow, but I'm sure it could be a little bit faster in Rust still. Fzy is noticeably faster for me, but it's bad at giving me the useful results first.

For command line tools I just appreciate if they're as fast as possible. And rg, fd, etc just show that Rust implementations can be correct and fast.