This is a fantastic write-up of a truly monumental effort. I have huge respect for the author's persistence. The line "Like gardening, but with more segfaults" really resonates. It’s this kind of deep-dive hobby project where you learn the most.
The experience with `c2rust` is particularly interesting. It reminds me of a similar shift I saw years ago with automatic code translators between other languages. They're incredible for getting a project off the ground and proving feasibility, just as the author found, but you often end up with code that's completely "un-idiomatic" for the target language. The decision to throw it all away and do a manual port, while surely gut-wrenching, was the right call. You just can't automatically translate the intent of the original C code into safe, idiomatic Rust.
The "Interesting Bugs" section gave me flashbacks. Bug #2, with the mismatched struct layout due to a missing `*`, is a classic FFI (Foreign Function Interface) nightmare. I once spent the better part of a week debugging a similar issue between C++ and C# where a single change in struct packing alignment was silently corrupting data downstream in very subtle ways. It's one of those bugs that makes you question your sanity. Finding that requires some serious debugging grit, so kudos to the author.
This project is a great case study in the real-world challenges of modernizing critical infrastructure code. The author mentions the next big goal is to convert the codebase from `unsafe` to safe Rust. I'm really curious about the strategy for that.
Refactoring away the raw pointers and complex control flow (like the `goto` patterns) into safe, idiomatic Rust without breaking everything seems like it would be even more challenging than the initial port. Will the approach be to introduce lifetimes and the borrow checker module-by-module? And what's the plan for the intrusive data structures? Replacing them with standard library collections like `BTreeMap` is the obvious choice, but I wonder if that will have performance implications that the original intrusive design was meant to avoid.
In any case, amazing work. Thanks for sharing the journey in such detail. I'll be following this project on GitHub for sure.
I've been working on a Rust-based tmux session manager called rmuxinator (i.e. tmuxinator clone) for a few years now. It (mostly) works and been slow going because ... life but I've recently picked it back up to fix some bugs. One of the last new features I'd added was the ability to use rmuxinator as a library in other Rust programs. I'd like to try forking 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. I'm definitely not advocating for adding rmuxinator upstream but it would be very nice to have this sort of session templating baked into the "terminal multiplexer" itself.
The other interesting possibility I could foresee is doing things the other way around and having rmuxinator use tmux-rs as a library in order to setup and manage sessions instead of just dumping out shell commands -- which is fraught with edge cases. (Not sure if this is currently possible with tmux-rs, though.)
Once I wrap up the bugfixes I'm currently working on, I may fork this project and give one or both of the above a try.
As of rmuxinator 4.0.0, you can now use tmux-rs as a configurable "terminal multiplexer" and it'll use that executable when shelling out to create and manage the session.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
Just curious. I'm a Rust developer. But I don't see myself discriminating between tools written in C, C++, Rust, Zig, etc. They all seem easy to install and use, as long as they're reasonably bugfree. Scripting languages are slightly different as they require me to maintain their respective interpreters and tools on my system. What difference do you see between applications written in Rust and those written in other compiled languages?
I agree the underlying technology doesn’t ultimately matter, but as user of a lot of fairly modern rust-based cli tools there definitely is something in the air worth mentioning.
I suspect it’s a couple of things. A new generation of programmers are hitting the scene, wanting to do things in new ways. Not inherently good or bad, but the new tools sure usually are at least very _pretty_, and have a lot of affordances and usability improvements over the ancient tools that can never be changed for the sake of compatibility. Rust and Go make this nicer, and are the languages de jour with good cli ecosystems and performance characteristics around them.
I genuinely do like most of my replacements. ripgrep for grep, eza for ls, zoxide for cd, fd for find, podman for docker, and a few more. Developer tooling is a rich and interesting space to be in, but there’s plenty of bandwagons I’m not getting on, like this or zellij for tmux, or jj for git.
Build Systems for C(++) are a mess, no package manager often means git submodules. Whereas Rust is actually easy, just requiring an `cargo install`. Don't know about Zig though Zig hasn't really taken of just yet imo.
What @tkcranny said. They are better usability now and more sensible defaults. I also find them marginally faster.
I also using them as way of supporting them. Tmux is great and I have used for years. Zellij is not there yet but does some things better than tmux too.
I love the attitude on this project and most of the comments are supportive. While rewriting a mature application to another language always sounds like a bad idea, there are so many learnings along the way. It's not about the end it's about the process.
Given the traction you got here and the advancements in AI, I'm sure this can become a very attractive hobby project for Rust beginners, there's probably a lot of easy bugs to fix. Fixing bugs, adding new features, and optimizing the code is all you need.
Here's an idea to get the ball rolling: Create a scratch buffer for Gemini CLI (or your favorite LLM) and enable it to interact with the various windows and panes of the tmux session.
Here's my use case, I use synchronized panes to send the commands into multiple servers, but some commands sometimes fail for various reasons. What if I can just ask the AI to send a series of commands and react based on the output and adjust along the way. It's like a dynamically generated custom shell script on the fly.
I'm all for people doing whatever hobby project they want to do for learning and entertainment purposes. But I don't really understand the appeal of straight porting something from one language to another.
For example, I'm a daily gvim user. If I were going to do a hobby project text editor, I would emphatically not make a clone of gvim, I'd make a text editor with exactly the features I want that behaves exactly how I want. If you're going to invest that much time in a project, why not do something creative and unique?
> my feeling is that I’d still reach for it if my hands are really physically hurting, and I need to keep working. Usually once I reach the point where I’ve got blisters on my fingers I think it’s better to just take a break
I'm dumbfounded, and impressed in an unhealthy way. Do some of you regularly type so much that you develop blisters?
Every day when I look in the mirror, and I don't have this problem.
Then again, by the time I had a touch typing course at age ten using an old typewriter, I already had taken piano lessons for a couple of years. My music teacher was very strict on proper hand positioning, saying that future me would hate him if I didn't learn that right. I stopped taking piano lessons soon after, but I imagine that the skills involved with properly playing the piano transfer quite well to typing.
Some of that video is about stuff you have no use for if you're not a Rust developer, but, some of it is things that would be just as useful to anybody who is comfortable with, as it says, a command line interface.
It's probably foolish, but I have the idée fixe that there's really no solid alternative for graphviz and dot (yes, there are UI versions, and mermaid and whatnot, but nothing that works on really big graphs and has the same expressivity), and I suspect that soon all the people that wrote graphviz will die off or retire. I like to see a port to a newer language as well, so ongoing maintenance will bercome easier.
Again, probably an idée fixe, and all is really well.
Readit News
The experience with `c2rust` is particularly interesting. It reminds me of a similar shift I saw years ago with automatic code translators between other languages. They're incredible for getting a project off the ground and proving feasibility, just as the author found, but you often end up with code that's completely "un-idiomatic" for the target language. The decision to throw it all away and do a manual port, while surely gut-wrenching, was the right call. You just can't automatically translate the intent of the original C code into safe, idiomatic Rust.
The "Interesting Bugs" section gave me flashbacks. Bug #2, with the mismatched struct layout due to a missing `*`, is a classic FFI (Foreign Function Interface) nightmare. I once spent the better part of a week debugging a similar issue between C++ and C# where a single change in struct packing alignment was silently corrupting data downstream in very subtle ways. It's one of those bugs that makes you question your sanity. Finding that requires some serious debugging grit, so kudos to the author.
This project is a great case study in the real-world challenges of modernizing critical infrastructure code. The author mentions the next big goal is to convert the codebase from `unsafe` to safe Rust. I'm really curious about the strategy for that.
Refactoring away the raw pointers and complex control flow (like the `goto` patterns) into safe, idiomatic Rust without breaking everything seems like it would be even more challenging than the initial port. Will the approach be to introduce lifetimes and the borrow checker module-by-module? And what's the plan for the intrusive data structures? Replacing them with standard library collections like `BTreeMap` is the obvious choice, but I wonder if that will have performance implications that the original intrusive design was meant to avoid.
In any case, amazing work. Thanks for sharing the journey in such detail. I'll be following this project on GitHub for sure.
Dead Comment
Dead Comment
I've been working on a Rust-based tmux session manager called rmuxinator (i.e. tmuxinator clone) for a few years now. It (mostly) works and been slow going because ... life but I've recently picked it back up to fix some bugs. One of the last new features I'd added was the ability to use rmuxinator as a library in other Rust programs. I'd like to try forking 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. I'm definitely not advocating for adding rmuxinator upstream but it would be very nice to have this sort of session templating baked into the "terminal multiplexer" itself.
The other interesting possibility I could foresee is doing things the other way around and having rmuxinator use tmux-rs as a library in order to setup and manage sessions instead of just dumping out shell commands -- which is fraught with edge cases. (Not sure if this is currently possible with tmux-rs, though.)
Once I wrap up the bugfixes I'm currently working on, I may fork this project and give one or both of the above a try.
Regardless, nice work by richardscollin!
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.
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
[1] jhawthorn/fzy: :mag: A simple, fast fuzzy finder for the terminal https://share.google/TBp3pVaFngBTfaFyO
And frankly, to quote Knuth
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.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.
interesting, I'm new to rust. what are you doing that necessitates using unsafe?
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.
Deleted Comment
But tmux isn't new
Is a reason necessarily needed to rewrite software in other languages
Edit: apparently it did turn out to be a lot of unsafe code
> 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.
Every new project is bound to have bugs that need to be ironed out during the time.
No, not at all. Rewrite all the things in Rust. if you enjoy it, do it. It leads to learning and learning leads to new innovation.
If you enjoy making it in Rust, then I'll enjoy trying it out.
Deleted Comment
Dead Comment
Deleted Comment
Or copies of old things apparently.
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.
I suspect it’s a couple of things. A new generation of programmers are hitting the scene, wanting to do things in new ways. Not inherently good or bad, but the new tools sure usually are at least very _pretty_, and have a lot of affordances and usability improvements over the ancient tools that can never be changed for the sake of compatibility. Rust and Go make this nicer, and are the languages de jour with good cli ecosystems and performance characteristics around them.
I genuinely do like most of my replacements. ripgrep for grep, eza for ls, zoxide for cd, fd for find, podman for docker, and a few more. Developer tooling is a rich and interesting space to be in, but there’s plenty of bandwagons I’m not getting on, like this or zellij for tmux, or jj for git.
I also using them as way of supporting them. Tmux is great and I have used for years. Zellij is not there yet but does some things better than tmux too.
Given the traction you got here and the advancements in AI, I'm sure this can become a very attractive hobby project for Rust beginners, there's probably a lot of easy bugs to fix. Fixing bugs, adding new features, and optimizing the code is all you need.
Here's an idea to get the ball rolling: Create a scratch buffer for Gemini CLI (or your favorite LLM) and enable it to interact with the various windows and panes of the tmux session.
Here's my use case, I use synchronized panes to send the commands into multiple servers, but some commands sometimes fail for various reasons. What if I can just ask the AI to send a series of commands and react based on the output and adjust along the way. It's like a dynamically generated custom shell script on the fly.
For example, I'm a daily gvim user. If I were going to do a hobby project text editor, I would emphatically not make a clone of gvim, I'd make a text editor with exactly the features I want that behaves exactly how I want. If you're going to invest that much time in a project, why not do something creative and unique?
> my feeling is that I’d still reach for it if my hands are really physically hurting, and I need to keep working. Usually once I reach the point where I’ve got blisters on my fingers I think it’s better to just take a break
I'm dumbfounded, and impressed in an unhealthy way. Do some of you regularly type so much that you develop blisters?
Then again, by the time I had a touch typing course at age ten using an old typewriter, I already had taken piano lessons for a couple of years. My music teacher was very strict on proper hand positioning, saying that future me would hate him if I didn't learn that right. I stopped taking piano lessons soon after, but I imagine that the skills involved with properly playing the piano transfer quite well to typing.
https://www.youtube.com/watch?v=rWMQ-g2QDsI
Some of that video is about stuff you have no use for if you're not a Rust developer, but, some of it is things that would be just as useful to anybody who is comfortable with, as it says, a command line interface.
Works great and it's totally memory safe
It's probably foolish, but I have the idée fixe that there's really no solid alternative for graphviz and dot (yes, there are UI versions, and mermaid and whatnot, but nothing that works on really big graphs and has the same expressivity), and I suspect that soon all the people that wrote graphviz will die off or retire. I like to see a port to a newer language as well, so ongoing maintenance will bercome easier.
Again, probably an idée fixe, and all is really well.
Try to port it. Maybe it'll just work
Deleted Comment