Introducing tmux-rs

I like this post, one can learn a lot.

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

> But otherwise, maybe better not rewrite working code....

Except that the eventual result allows for extension and improvements in a memory-safe language.

There seems to be some rather irrational obsession about this.

Things can seem irrational when you don't understand them.

Another comment in this thread hoped for "a brand new bulletproof tmux-resurrect". The reason there's a desire for such things is closely related to the limitations of non-trivial programs written in C.

They're harder to extend without bugs, harder for new team members to understand, and so on.

The "irrational obsession" has to do with advancing the state of the art beyond a primitive high-level assembler that was developed in the 1970s.

I understand them very well, I just do not think 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 ecosytem costs.

Rust is far more portable in practice than C. Your average C program is written either for Unix or for Windows, while Rust has sufficient abstraction power to be able to write most business logic once.

I maintain cargo-nextest, a widely-used test runner for Rust. It is possible to write nextest's runner loop in C, but it would be extraordinarily difficult — each test's state machine has dozens of states, there are several dynamic event sources as inputs, and the event loop relies heavily on epoll/kqueue/the equivalent Windows thing, as abstracted out by Tokio. So most test runners written in C don't even try to approach the quality, reliability, or portability of nextest.

https://nexte.st/docs/design/architecture/runner-loop/

Looks like you think only in windows and linux. Ok, but how much of your rust runs on freeRTOS or bare metal and on how many processor families? C? Runs on all of them. 6502? No Problem? 8051? Clearly! CRC16C? Yes. Eco32? yup. i386? Is developed to run C. Arm64, Arm? They too. They run Minix in their internal controlling hardware. Written in C...

Rust is not portable at all compared with C code.