Most active commenters
  • (4)
  • godelski(3)

←back to thread

Introducing tmux-rs

(richardscollin.github.io)
857 points Jtsummers | 67 comments | | HN request time: 1.795s | source | bottom
1. mbreese ◴[] 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 #
2. upmind ◴[] No.44456003[source]
I found out that quite funny, I wonder how many hours he spent on this. It seems extremely monotonous haha
replies(3): >>44456163 #>>44456937 #>>44457622 #
3. ◴[] No.44456163[source]
4. nisegami ◴[] No.44456205[source]
Maybe my understanding of one or more concepts involves is wrong, but that "more segfaults" bit confuses me. Shouldn't the rust compiler prevent code that can segfault from compiling? Unless there was a lot of unsafe blocks involved.

Edit: apparently it did turn out to be a lot of unsafe code

replies(3): >>44456243 #>>44456244 #>>44457407 #
5. miroljub ◴[] No.44456243[source]
My understanding is that, even though tmux-rs is written in a safer language, it still can't beat the stability of an old battle-tested well-maintained project written by a group of highly competent developers.

Every new project is bound to have bugs that need to be ironed out during the time.

replies(4): >>44456531 #>>44456600 #>>44456731 #>>44456941 #
6. Jtsummers ◴[] No.44456244[source]
It's a transliteration. He's basically implemented a C program in Rust. He says in the conclusion the next goal is converting it to safe Rust.
7. Ar-Curunir ◴[] No.44456531{3}[source]
It’s just because there are a lot of unsafes, and because the translation from C to Rust introduced semantic-mismatch bugs
8. a_humean ◴[] No.44456600{3}[source]
They wrote everything in unsafe rust where its very possible to segfault. This is not a normal C to Rust port. In a normal port you would never aim to have 100% unsafe rust code - rather you would hive off small parts of your application where you need unsafe so its highlighted and auditable. This is clearly an excerise for fun.
replies(1): >>44458331 #
9. antonvs ◴[] No.44456731{3}[source]
No, the issue is that doing a direct translation from a fundamentally unsafe language like C can't fix safety issues.

You'd have to do a proper rewrite, in which case you could write safe code from the start.

> Every new project is bound to have bugs that need to be ironed out during the time.

Not on the level of the kind of critical security and reliability bugs that unsafe languages foster. That's why CISA and the FBI both strongly recommend memory-safe languages.

10. cultofmetatron ◴[] No.44456799[source]
> Like gardening, but with more segfaults.

interesting, I'm new to rust. what are you doing that necessitates using unsafe?

replies(2): >>44456889 #>>44457183 #
11. tshaddox ◴[] No.44456889[source]
I suspect it's vastly easier to port C to unsafe Rust than to safe Rust.
12. ziml77 ◴[] No.44456937[source]
Sometimes that's exactly what one needs. As long as there's not forced schedule for the work and you can do it when you want and at the pace that you want, it can feel good.
13. QuaternionsBhop ◴[] No.44456941{3}[source]
My understanding is that the author was referring to there being more segfaults in programming than in gardening.
replies(1): >>44456976 #
14. nicce ◴[] No.44456976{4}[source]
Both can be true at the same time in that sentence
15. planet36 ◴[] No.44457023[source]
"Gardening is the handiest excuse for being a philosopher." - Ray Bradbury, Dandelion Wine
16. tombert ◴[] 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 #
17. jeroenhd ◴[] No.44457183[source]
A lot of things that C will let you do (even if you enter the realm of undefined behaviour) will simply not compile to C. As the author states, there are semantic differences between pointers and Rust's references.

C pointers can have as many owners as you want, may be subjected to mathematical operations, and can be cast to any type without even an error message. The compiler will just assume you know what you're doing. If you enable enough compiler warnings, it might warn you, but C compilers don't generate a lot of those by default.

Rust will let you only generate one mutable (exclusive) reference at a time. This means straight C to Rust ports simply don't compile.

By switching to pointers, which work pretty much like their C equivalent, you can port the code much easier, but you do of course lose the benefits of Rust's safety mechanisms, because most pointer operations throw away all the safety guarantee that Rust provides.

replies(3): >>44457388 #>>44459258 #>>44459618 #
18. SoftTalker ◴[] No.44457388{3}[source]
So what is the advantage of an unsafe Rust implementation? Just to have done it?
replies(5): >>44457474 #>>44457712 #>>44458531 #>>44458900 #>>44459852 #
19. ar_lan ◴[] No.44457407[source]
In the second sentence he mentions:

> the code base is now 100% (unsafe) Rust

I didn't interpret that it's 100% unsafe, but I do expect that to mean there is probably a lot of unsafe blocks used. A good amount of the example code in the post alone is unsafe blocks as well.

20. cuu508 ◴[] No.44457474{4}[source]
From the article: "The next goal is to convert the codebase to safe Rust."
21. phkahler ◴[] No.44457622[source]
I think knitting looks monotonous, but I can see the appeal.
22. petrzjunior ◴[] No.44457712{4}[source]
It is rewritten to a different language and many people find Rust easier to read, it has better type hint support for IDE etc. Also, you do not lose all the safety, there are still many rules enforced, such as safe linking, no undefined functions. Unsafe Rust means that all parts of code which do illegal pointer magic are explicitly marked with an "unsafe" keyword. You can now go one by one and fix them.
replies(1): >>44463506 #
23. rauli_ ◴[] No.44457783[source]
Not every code project needs to turn out to be world changing. Experiments like this sometimes produce excellent results.
24. dsp_person ◴[] No.44458165[source]
Looking forward to the tmux-c re-rewrite next
replies(1): >>44458544 #
25. godelski ◴[] No.44458298[source]
Honestly, I often hate how people ask "why?", and don't understand how "for fun" is a legitimate answer. I get it for work or other things, but hobbies? We do lots of things for fun! Humans were born to play, just like every other animal. It's how we learn and explore the world around us.

And frankly, to quote Knuth

  > In fact what I would like to see is thousands of computer scientists let loose to do whatever they want. That's what really advances the field.
This is true for any field, or any project. We're creative creatures. We dream and explore. Major changes almost never come from doing things the way they've always been done. A lot of times "just because" gives you the freedom to try new things and challenge those paradigms. Weirdly, if you always have to justify everything you slow down progress.
replies(4): >>44458491 #>>44459387 #>>44459582 #>>44460865 #
26. nicoburns ◴[] No.44458331{4}[source]
I think it is a normal porting process, it's just only half-finished at this point. The conversion to safe Rust is yet to come.
27. badgersnake ◴[] No.44458461[source]
> new things

Or copies of old things apparently.

28. Arisaka1 ◴[] No.44458491[source]
I still believe that my #1 think that stunted my growth as a junior SWE was overthinking my personal projects and languages to use for them, instead of just building whatever I felt it's interesting or intriguing to build.
replies(3): >>44459159 #>>44459191 #>>44461166 #
29. ◴[] No.44458531{4}[source]
30. carlmr ◴[] 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 #
31. tombert ◴[] No.44458823{3}[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...

32. kevincox ◴[] No.44458900{4}[source]
Once the codebase is all Rust you can start introducing Rust idioms and patterns. Basically step 1 is to get it working in Rust then step 2 is to clean up the Rust to actually take advantage of the language.
33. 90s_dev ◴[] No.44459018[source]
Intuition and logic are the two halfs of reason (logos). We sometimes have a reason that we can't put into words (logos) but we know intuitively.
34. godelski ◴[] No.44459159{3}[source]
It's always hard to tell. But have you considered you might be measuring the wrong way?

To me it sounds like you learned a real important lesson one that some people never seem to learn.

I think one of the most beneficial aspects of doing things "just because" is these other skills or information you get along the way. It is very easy to miss all of this progress if you're too focused on the progress of the more tangible things. But that doesn't make any of that not progress. So don't put yourself down for that, because I'm sure you learned a lot. The only reason you can look back and see a better way is because you made that progress and learned those lessons. These are things mentors can usually help you get through faster but not everyone has a mentor nor access to one. But don't undermine your own progress just because you didn't finish projects or because you did things differently than others

35. ku1ik ◴[] No.44459191{3}[source]
Same here!
36. zozbot234 ◴[] No.44459258{3}[source]
> Rust will let you only generate one mutable (exclusive) reference at a time.

Safe Rust includes many forms of shared mutability, including Cell<> which is perhaps the closest comparison to typical patterns in C code.

37. serial_dev ◴[] No.44459387[source]
Asking “why” can still be a legitimate question, and “for fun” can also be a legitimate answer.

I treat projects differently if they want to launch a product, they want to replace an established open source tool, done for fun for themselves, or if it’s a hobby project.

replies(2): >>44460210 #>>44461399 #
38. ◴[] No.44459396[source]
39. 1vuio0pswjnm7 ◴[] No.44459476[source]
"We don't necessarily need a reason to build new things."

But tmux isn't new

Is a reason necessarily needed to rewrite software in other languages

replies(1): >>44459486 #
40. fragmede ◴[] No.44459486[source]
GNU screen would like a word.
replies(2): >>44459946 #>>44464601 #
41. charcircuit ◴[] No.44459582[source]
There is more than 1 way to have fun. Some ways of having fun will produce more value to other people than others.
42. krater23 ◴[] No.44459618{3}[source]
Hmm...I like when the compiler don't steps in my way and assumes that I know what I'm doing. Thats the reason why I don't like Rust. But when you like it, have fun!
replies(1): >>44459732 #
43. anyfoo ◴[] No.44459732{4}[source]
"Hmm...I like when the assembler don't steps in my way and assumes that I know what I'm doing. Thats the reason why I don't like C, and prefer assembler. But when you like it, have fun!"
replies(1): >>44461018 #
44. sedatk ◴[] No.44459852{4}[source]
In addition to other points about making it progressively safe, unsafe Rust is still safer than C. https://bsky.app/profile/ssg.dev/post/3lkjogvm2c222
replies(1): >>44460750 #
45. sherburt3 ◴[] No.44459885[source]
I was about to post a snarky comment because I have a knee jerk reaction whenever someone implies a rust application is intrinsically better than C. Sometimes I forget people do things for fun.
46. magarnicle ◴[] No.44459946{3}[source]
I really don't know how tmux got so much mindshare over screen. It just isn't obviously better in any way. Maybe screen is just poorly named?
replies(3): >>44460431 #>>44461072 #>>44512955 #
47. godelski ◴[] No.44460210{3}[source]
The complaint isn't about being asked why, it is about "for fun" not being acceptable.

Follow up questions are totally cool but the context is different, right?

If it isn't acceptable then there's a negative tone and questions are focused on utility and usually them "trying to help you" find utility.

If it is acceptable they ask you about your interests and what you're learning. Sometimes that can turn into utility but that's more natural.

It's a lot about culture to be honest. Some people are just toxic and if things don't make sense in their heads then it doesn't make sense in any head.

48. usef- ◴[] No.44460431{4}[source]
I think a lot of it is that tmux had friendler, sane defaults and clearer command design (eg. status bar out of the box). And, I suspect, people not already knowing screen.

The latter reason is why Helix is slow in doing similar to vim, I think, despite being far more consistently designed and saner defaults. Everyone knows vim exists.

I've still never switched from screen, personally, though I'm only a light user.

replies(1): >>44460811 #
49. Nadya ◴[] No.44460750{5}[source]
Rust is like walking across a mine field with all the mines flagged for you. You can dig up the mine and remove the flags over time. Or at least know to avoid stepping carelessly around them.

In C you only see the flags people know of or remembered to plant. There's an awful lot of mines left unflagged and sometimes you step on them.

It's very obvious to me which would be more safe and I find myself questioning why it is isn't so obvious to others.

50. quotemstr ◴[] No.44460811{5}[source]
> status bar out of the box

Software packages win over other packages for the silliest reasons.

replies(2): >>44461752 #>>44462538 #
51. hamandcheese ◴[] No.44460865[source]
I suspect they do understand that "for fun" is a reasonable answer. The disconnect is probably that they don't see how your hobby could be fun.
52. BigJono ◴[] No.44461018{5}[source]
C code is shorter than both assembly and Rust, it's not the same thing.
replies(1): >>44475693 #
53. telotortium ◴[] No.44461072{4}[source]
Screen couldn’t do vertical splits for the longest time. That started to be a bigger problem when screens got bigger and wider. I believe that’s why I started using tmux. Tmux also has more facilities for automation. Nowadays, screen is primarily in maintenance mode, and I’m used to tmux, so no reason to switch back.
replies(1): >>44461217 #
54. Quiark ◴[] No.44461166{3}[source]
you cultivated your interest in programming languages and techniques

other people use the stupidest possible javascript to launch product and really focus on product and marketing

yet other people stay as far away from computers as possible and focus on more human activities

you just do what you're drawn to naturally

55. unixhero ◴[] No.44461217{5}[source]
Tmux for a lot of things, including scripts

Screen for when I need things ti behave and work a certain way

56. goku12 ◴[] No.44461399{3}[source]
'For fun' is a perfectly reasonable answer. But sometimes the answer to 'why' comes after you do it. I'm sure that everyone has learned something without realizing its utility until the end. Nobody is obligated to answer that question, unless you're pitching something.
57. vaylian ◴[] No.44461752{6}[source]
Defaults matter. I've had my screenrc with a status line but I still ended up preferring tmux in the end, because not needing a config file was a small but pleasant advantage when working with different machines. I also didn't like ctrl+a as the leader combination, because it conflicts with "go to the beginning of the line" in bash. ctrl+b is a much nicer default.
58. ricardobeat ◴[] No.44462280{3}[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 #
59. milliams ◴[] No.44462406{3}[source]
Well there's been skim (https://github.com/skim-rs/skim) for a while as a fzf equivalent in Rust.
60. Mawr ◴[] No.44462538{6}[source]
The status bar displays key information to the user. Do you think people would prefer a video player with no play/pause, volume, seekbar or one with them? The interface is the most important part of any application.
61. ◴[] No.44463066[source]
62. carlmr ◴[] No.44463432{4}[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.

63. techbrovanguard ◴[] No.44464127{6}[source]
> chuckles

jesus christ, you’re not light yagami—please stay on /g/

replies(2): >>44464177 #>>44474167 #
64. lproven ◴[] No.44464601{3}[source]
> GNU screen would like a word.

Screen, tmux, byobu, dvtm, mtm, Twin, and most of all Zellij, which is basically "tmux but redone in Rust".

I tried to compare them all a month ago:

https://www.theregister.com/2025/06/24/tiling_multiplexers_s...

65. johnisgood ◴[] No.44474167{7}[source]
Someone is going on a witch-hunt. Most of my comments under this submission are flagged, including this one: https://news.ycombinator.com/item?id=44464177.

Crazy. They have gotten quite a lot of upvotes, for the record, but feel free to flag ALL of my comments.

I wonder what is so wrong about asking if I cannot chuckle anymore, so wrong that it warrants it to be flagged.

>> chuckles (written by me)

> jesus christ, you’re not light yagami—please stay on /g/ (written by some individual)

However, is not flagged. It would be hilarious if it was not so sad.

66. anyfoo ◴[] No.44475693{6}[source]
Both rust and C are also much, much less error-prone than assembly. It is so, so easy to get things wrong in assembly in very subtle ways. That’s one of the main drivers while people are only writing assembly today when they absolutely have to.
67. tremon ◴[] No.44512955{4}[source]
There's two things that made me switch from tmux to screen:

- persistence of layouts. Screen doesn't remember if you had a split view open, it always opens the current terminal in full screen.

- screen's default hotkey ^A clashes with ssh's escape key. Yes, these are configurable but having to re-populate the same config file is like a papercut every time to access a new system.

Defaults matter, especially if you work across many different systems (and from different customers). At some point, it just becomes easier to learn the defaults than to (over-)optimize to your ideal workflow.