←back to thread

Introducing tmux-rs

(richardscollin.github.io)
857 points Jtsummers | 5 comments | | HN request time: 1.106s | source
Show context
starchild3001 ◴[] No.44460169[source]
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.

replies(2): >>44460948 #>>44463452 #
johnisgood[dead post] ◴[] No.44463452[source]
[flagged]
Touche ◴[] No.44463712[source]
This person built a really cool project and documented how and you're throwing negative predictions about it for no reason. No one is down voting your opinions on OpenBSD
replies(1): >>44463768 #
johnisgood[dead post] ◴[] No.44463768[source]
[flagged]
ga_to ◴[] No.44463823[source]
But it's _not_ c2rust. It started that way but this approach was abandoned in favor of a manual port. From the comment you replied to: > 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.

From the second paragraph of TFA: > I threw away all of the C2Rust output and decided I would translate all of the files into Rust manually from C.

Please at least read the source before shit-talking it.

replies(1): >>44463929 #
johnisgood[dead post] ◴[] No.44463929[source]
[flagged]
1. OneDeuxTriSeiGo ◴[] No.44465306[source]
The author literally said they were not aiming for idiomatic rust. They were focusing on translating as directly from C to Rust as possible.

If you still think they are using a transpiler rather than doing rote hand translation, please point out some specifics.

replies(1): >>44465846 #
2. johnisgood ◴[] No.44465846[source]
Example: https://github.com/richardscollin/tmux-rs/blob/main/src/file...

You are right, it is very far off from idiomatic Rust. It could have been done in virtually any programming languages. I am not sure why Rust was chosen if they decided to go against everything Rust stands for.

replies(1): >>44465999 #
3. OneDeuxTriSeiGo ◴[] No.44465999[source]
This is how a lot of rewrite projects start out, particularly in the hobby space. They focus on a 1:1 translation between the two languages until they're able to drop the original language's dependencies (compiler, etc). Then from there you start translating into idiomatic rust.
replies(1): >>44471726 #
4. johnisgood ◴[] No.44471726{3}[source]
I have never seen rewrite projects start out this way. What is the point of the rewrite then, if this is 1:1? You will definitely implement bugs, too, and most likely introduce more.
replies(1): >>44474438 #
5. OneDeuxTriSeiGo ◴[] No.44474438{4}[source]
Any ship of theseus rewrite is going to introduce bugs in the process, either by translating it 1:1 first or by replacing code with rust and talking over FFI.

The appeal of translating to rust first is that 1. you intimately learn a codebase you did not write, 2. you can refactor code during the following stages of the rewrite without worrying about FFI boundaries (which are their own massive source of complexity), and 3. you can work entirely in an ecosystem you prefer rather than attempting to work with tooling across ecosystems.

I personally prefer this 1:1 approach for hobby projects (where notably you don't have to continue maintaining a working product while the rewrite is in progress) because you can refactor in passes rather than in sections but it does have it's own drawbacks (added bugs/changed behavior from translation, etc) that you have to compensate for with additional tooling (like fuzz testing, conformance testing, etc).