Essential insights from Hacker News discussions

Introducing tmux-rs

This discussion revolves around a project to rewrite the tmux terminal multiplexer in Rust. Key themes emerge regarding the motivation for such a project, the use of unsafe Rust, the process of porting from C to Rust, and the overall value of hobby projects.

This lengthy and detailed discussion can be summarized by the following major themes:

The Hobbyistic Nature and Value of Rewriting Projects

A significant portion of the conversation centers on the idea that not all projects need a grand, world-changing purpose. The author's admitted lack of a strong justification for the rewrite, comparing it to gardening, resonated with many users. This perspective highlights the intrinsic value of learning and exploration through personal projects.

  • "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!" (mbreese)
  • "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." (ziml77)
  • "Honestly, I often hate how people ask "why?", and don't recognize how "for fun" is a legitimate answer. 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." (godelski)
  • "Not every code project needs to turn out to be world changing. Experiments like this sometimes produce excellent results." (rauli_)
  • "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." (tombert)
  • "As a hobby project, all power to you. But otherwise, maybe better not rewrite working code...." (uecker)
  • "Great way to learn a new language!" (aldousd666)
  • "It's not about the end it's about the process." (gmoque)

The Role and Implications of unsafe Rust

The project's use of unsafe Rust is a prominent point of discussion. Users debate whether this negates Rust's primary advantage of memory safety and how it relates to the direct porting process from C. The author's explicit mention of starting with unsafe Rust and the intention to eventually move to safe Rust is a key detail many comment on.

  • "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." (nisegami)
  • "Edit: apparently it did turn out to be a lot of unsafe code" (nisegami)
  • "It’s just because there are a lot of unsafes, and because the translation from C to Rust introduced semantic-mismatch bugs" (Ar-Curunir)
  • "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 exercise for fun." (a_humean)
  • "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." (antonvs)
  • "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." (a_humean)
  • "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." (nicoburns)
  • "The next goal is to convert the codebase to safe Rust." (cuu508)
  • "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." (petrzjunior)
  • "I suspect it's vastly easier to port C to unsafe Rust than to safe Rust." (tshaddox)
  • "So what is the advantage of an unsafe Rust implementation? Just to have done it?" (SoftTalker)
  • "It's the first step in a two-step process: 1. Rewrite in (unsafe) Rust. 2. Update the code over time, moving towards safe Rust. It's the old, "get it working then fix it" process. In business that's normally a bad idea because you end up wasting more time than if you'd just done things correctly from the start but for a hobby project it's fine. Because then you're more likely to learn something and possibly—ultimately—end up with a better end product." (riskable)
  • "My immediate reaction was: 1) 25% more LOC, 2) in unsafe Rust, 3) for a tool that already has great maintainence." (busterarm)
  • "I like the initiative, but all this effort for ... unsafe Rust? I know it's a hot topic, and I hope the end goal is to have a memory-safe (and faster) tmux. I just hope the author doesn't stop here :)" (denysvitali)
  • "At the end of the article he states that the next step is to work toward safe Rust." (verbatim)
  • "It's 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." (a_humean)

The Challenges and Nuances of Porting from C to Rust

The discussion delves into the technical difficulties of translating C code to Rust, particularly when dealing with C's flexible pointer semantics and the goal of maintaining equivalent functionality. The author's decision to manually translate the code rather than relying solely on automated tools like c2rust is also a key point.

  • "Nisegami: 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." (nisegami)
  • "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." (miroljub)
  • "It’s just because there are a lot of unsafes, and because the translation from C to Rust introduced semantic-mismatch bugs" (Ar-Curunir)
  • "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." (jeroenhd)
  • "I threw away all of the C2Rust output and decided I would translate all of the files into Rust manually from C." (quoted from the article by neuspadrin)
  • "I threw away all of the C2Rust output and decided I would translate all of the files into Rust manually from C. Neither seems doing it manually: "I introduced many bugs while translating the code. I’d like to share the process of discovering and fixing a couple." Or using AI: "That’s because when using cursor to translate the code it would still occasionally insert bugs, just like me. So, I spent as much time reviewing the generated code as it would have taken me to write it myself."" (uecker)
  • "Is this a joke? Have you seen the generated Rust code? This is not an actual rewrite. Edit: I was right, they used c2rust. And then there is "// generated Rust code". As for the code snippets on ... I can read the C version better than the generated Rust code." (johnisgood)
  • "It is auto-generated with the purpose of maintaining the exact same semantics as the C code, with no regard to safety, best practices, etc.—of course it is messier than actual, handwritten Rust." (jonpalmisc)
  • "The next goal is to convert the codebase to safe Rust." (jonpalmisc, quoting the article)
  • "Seems like you didn't read the article at all. The author talks about writing it themselves after finding the automatically generated code not up to snuff." (aniforprez)
  • "This seems like an excellent future use case for a fully automated process by a large language model that translates a non-trivial C codebase to Safe Rust in under an hour with high accuracy. However, as the author noted, even after some attempts with Cursor at the end of development, the tool wasn't able to accelerate the translation effectively (in mid-2025). So while the potential is promising, it appears we're still some way off." (rthnbgrredf)
  • "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." (Jtsummers)

The Perception of Rust and its Adoption

Some users discuss Rust's current standing and how that influences the attention given to projects like this. There's also commentary on whether Rust is truly an improvement over C and its perceived downsides.

  • "The only reason this is at the top of HN is because of where Rust is on the Gartner Hype Cycle right now." (busterarm)
  • "But otherwise, maybe better not rewrite working code.... Except that the eventual result allows for extension and improvements in a memory-safe language." (antonvs)
  • "It seems a lot of people are irrationally obsessed with this. I understand it quite well, I just do not think that it trumps all other considerations. Also I do not believe that Rust is easier than C. It is also less fun, less portable, and has another annoying ecosystem costs." (uecker)
  • "There's a lot of subjectivity here. The last serious C code I wrote was in the early 1990s, and I don't miss it at all, because I don't like spending time on low-level details unrelated to the problem domain I'm working on. I find Rust fun and easy for writing system-level code, and I have enormous appreciation for the degree of correctness-by-construction that it can provide. Generally, if it builds, it works, as long as you're making proper use of the type system - make illegal states unrepresentable, as the saying goes. That's very difficult to do with C. Rust isn't perfect. For most things, I'd rather be using Haskell, ML, or something on that level. But it's still on a completely different level from C, and rewriting the software ecosystem in it can only be an improvement." (antonvs)
  • "You can say something similar about COBOL and FORTRAN. C's fundamental flaws aren't being fixed, because that would require a new language. There comes a point at which it becomes necessary to move on." (antonvs)
  • "What in your mind are the fundamental issues of C? Because memory safety clearly isn't one of them as brand new systems languages are being written without it (Zig)." (Spivak)
  • "Absolutely zero shade to Zig, because it is still pre-1.0, but if you look at which new systems languages have gained wide adoption recently, instead of languages that are just created, you end up with Rust. And the stated reason industry is adopting it is memory safety." (steveklabnik)
  • "It comes from the fact that nearly every useful program written in C has multiple security vulnerabilities just waiting to be found. In the unlikely event that you have a codebase that's free of them, you risk introducing one with any significant change." (wat10000)
  • "Tmux has been used a lot of memory on my system, especially when scrolling buffer is large enough (I often have > 10k lines of things ). I have often executed pkill -9 tmux and saved my day. I hope the rust version can help a bit here?" (df0b9f169d54)

AI and Code Translation Tools

The role of AI, specifically LLMs and tools like Cursor, in code translation is a recurring topic. Users discuss their effectiveness, limitations, and future potential for such tasks.

  • "The people demand the AI angle." (keybored)
  • "This seems like an excellent future use case for a fully automated process by a large language model that translates a non-trivial C codebase to Safe Rust in under an hour with high accuracy. However, as the author noted, even after some attempts with Cursor at the end of development, the tool wasn't able to accelerate the translation effectively (in mid-2025). So while the potential is promising, it appears we're still some way off." (rthnbgrredf)
  • "These folks[0] are doing it, possibly via "codemods"[1], which utilize ASTs." (gavmor)
  • "LLM's are really good at translating one programming language into another." (londons_explore)
  • "I was hoping for the announcement of a brand new bulletproof tmux-resurrect. But no, it is (just) tmux-(recodedIn)rust." (lolive)
  • "Interesting, this article and the comments make no mention of LLMs for the initial translation. Really surprising given that would be the first thing I'd reach for for a translation/porting task (though verification could get tricky)." (parhamn)
  • "It wouldnt have gotten 2% finishd. It wouldn't have compiled. Its a waste of time to even consider." (TechDebtDevin)
  • "rewriting old code in new language is the killer application for AI. should have used that instead of transpilor." (z3ratul163071)
  • "Using Cursor to refactor the unsafe code is quite a different task than using an LLM to translate into safe rust. I was just curious how it would perform." (parhamn)
  • "Does the article mention using LLMs? Yes, the author states: I did start trying out Cursor towards the end of the development process. I ended up stopping using it though because I felt like it didn’t actually increase my speed. It only saved me from finger pain. That’s because when using cursor to translate the code it would still occasionally insert bugs, just like me. So, I spent as much time reviewing the generated code as it would have taken me to write it myself. The only thing it saved was my hands. Doing this large amount of refactoring is really hard on your fingers." (Jtsummers)

Specific Features and Alternatives

Some discussion touches on requested tmux features and alternative terminal multiplexers.

  • "Nice, hope it will become cleaner code in time. I tried zellij multiple times but despite years of development it still misses many things tmux provides. Inability to show/hide status bar[1] is the most annoying." (xvilka)
  • "I love this. I also want to dabble into loving things to rust! Here I want to call out zellij. Zellij is rust based terminal multiplexer. I am user not creator. I love everything rust and finding and migrating to rust based solutions where feasible." (tekawade)
  • "I use byobu which is basically an opinionated distribution of tmux. Scroll wheel works fine, as does Alt-PgUp/PgDn. Ctrl-Tab probably won't work because terminals tend not to recognize it as different from Tab. But you might be able to bind Alt-Tab or some other such combo to cycle through panes in the tmux config. It should just be a one-liner." (antonvs)
  • "You might like zellij more than tmux." (0x457)
  • "Tmux is a gamechanger for me. Being able to start a dozen different projects with one line (using tmuxinator): the server, tailing logfiles, activating venvs, running the docker container, all within one line of code: Awesome." (submeta)
  • "I've been working on a Rust-based tmux session manager called rmuxinator (i.e. tmuxinator clone) for a few years now." (ethagnawl)
  • "I wonder if the tmux maintainers would be interested in switching to this? Transitioning more software from C to Rust is a great idea." (echelon)
  • "My understanding is that tmux is primarily an OpenBSD project, and rust isn't a good fit for them (for reasons that summarize to portability problems), so it is extremely unlikely." (yjftsjthsd-h)
  • "I'd like to forked tmux-rs, adding rmuxinator as a dependency and seeing if it would ... just work as a way to start sessions using per-project config files." (ethagnawl)
  • "I'm surprised to hear you migrated from iTerm. It actually has a tmux integration mode (using -CC) that's awesome. You then don't have to remember any tmux specific shortcuts. Switching window is just Cmd+` just like everywhere else. I entirely stopped using tmux when I couldn't use iTerm." (kccqzy)
  • "a_humean: 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." (a_humean)