HN Reader

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.

Regardless, nice work by richardscollin!

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 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.

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.

> 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?

Works great and it's totally memory safe

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.

So the primary (or rather: only) reason for using Rust over C (memory safety) is out the window.

> I’d like to share the process of porting the original codebase from ~67,000 lines of C code to ~81,000 lines of Rust

And the codebase got bigger.

So yeah, as the author explains, hobby project, and kudos to that, but nothing that I will install on any box of mine any time soon.

Besides, applications like tmux would much rather be prime candidates for a rewrite in a garbage collected systems language (aka.; Go) than in Rust. tmux spends 99% of its time waiting for the user to hit a key, there is nothing performance critical in such an app that wouldn't be 100% adequately served by Go.

From now on, it's like gardening, but in hell :-)

  I walked through the code again. Inside of the Rust function (*c).bar has a valid address, like 0x60302764, but out the function, the value received from the calling C code was 0x2764.

  ...

  That’s right, the C code was using the implicit declaration which is:
   
  int get_addr();
  
  That explains why the value was incorrect! The C compiler was thinking a 4 byte int was returned not an 8 byte pointer. So the top 4 bytes were being truncated or ignored.

[1] https://github.com/zellij-org/zellij/issues/694

Sorry I know this is not the place to complain, but it would be so nice!

I was surprised to learn tmux had such a "large" codebase, where does the complexity come from?

I have often executed `pkill -9 tmux` and saved my day. I hope the rust version can help a bit here?

Love it. You definitively deserve your +350 points!

Looking forward to check out tmux-rs.

And as a result, you could be running the greatest / fastest / most feature rich desktop terminal … but if your multiplier doesn’t support something - it hinders your fancy desktop terminal.

Short 3 min video explained by Ghostty creator

https://youtu.be/o-qtso47ECk

Which makes C2Rust seem pretty useless?

"I’ve recently reached a big milestone: the code base is now 100% (unsafe) Rust. I’d like to share the process of porting the original codebase from ~67,000 lines of C code to ~81,000 lines of Rust (excluding comments and empty lines)."

And yet somehow a hand-ported (and still unsafe) rewrite of a C program in Rust is still almost 20% larger?

If I recall, the Go gc compiler was automatically converted from 80K lines of C to 80K lines of Go. A hand-ported version would have been much smaller.

120 comments and nobody has mentioned the use-after-free triggered by closing a window. Rust truly is the safest language.

Sounds to me that this was a C -> Rust transpiler. :D

Edit: I was right, they used c2rust.

And then there is "// generated Rust code".

As for the code snippets on https://richardscollin.github.io/tmux-rs/, I can read the C version better than the generated Rust code.

  // cmd-kill-session.c
  RB_FOREACH(wl, winlinks, &s->windows) {
    wl->window->flags &= ~WINDOW_ALERTFLAGS;
    wl->flags &= ~WINLINK_ALERTFLAGS;
  }

  // cmd_kill_session.rs
  for wl in rb_foreach(&raw mut (*s).windows).map(NonNull::as_ptr) {
      (*(*wl).window).flags &= !WINDOW_ALERTFLAGS;
      (*wl).flags &= !WINLINK_ALERTFLAGS;
  }

What a legend.

Edit: As pointed out below, I'm stupid, it's stated in the article and I didn't read that part

It seems automatically translating Rust to C is not a very good idea: "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."

As a hobby project, all power to you. But otherwise, maybe better not rewrite working code....

Transitioning more software from C to Rust is a great idea.

you want to re-implement a well known project, fine

call it something else

I was hoping for the announcement of a brand new bulletproof tmux-resurrect.

But no, it is (just) tmux-(recodedIn)rust.

Like they’ve basically thrown away all the rust patterns and just wrote a c program in rust (eg all the raw pointers)

In fact, I sometimes port code to another language and back just as a way to do code cleanup (or at least give ideas for things that could be cleaned up)

I wonder why OP didn't start from that as a starting point?

Now I really wonder how a good model like Sonnet 4 would have performed.