←back to thread

Introducing tmux-rs

(richardscollin.github.io)
857 points Jtsummers | 2 comments | | HN request time: 0.417s | source
Show context
uecker ◴[] No.44456333[source]
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....

replies(4): >>44456413 #>>44456755 #>>44459370 #>>44459965 #
antonvs ◴[] No.44456755[source]
> But otherwise, maybe better not rewrite working code....

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

replies(2): >>44456866 #>>44458838 #
uecker ◴[] No.44456866[source]
There seems to be some rather irrational obsession about this.
replies(2): >>44456899 #>>44457353 #
antonvs ◴[] No.44456899[source]
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.

replies(4): >>44456943 #>>44457046 #>>44459920 #>>44460258 #
uecker ◴[] No.44456943[source]
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.
replies(3): >>44457035 #>>44457061 #>>44458426 #
sunshowers ◴[] No.44458426[source]
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/

replies(2): >>44458762 #>>44459672 #
uecker ◴[] No.44458762[source]
I think you have no idea how big the C ecosystem is. I am not sure what cargo-nextest is, but I have seen people solve the most challenging programs in C.
replies(1): >>44458924 #
sunshowers ◴[] No.44458924[source]
As I mentioned, cargo-nextest is a widely used test runner for Rust -- you're welcome to check out its website for its feature set.

It is possible to do this in C, because it compiles to machine code in the end. But would be out of reach for all but the most talented of C teams working over many years, and the portability costs would be massive. As a result, I don't know of a test runner that comes anywhere close to the feature set and portability of nextest that's written in C.

> I think you have no idea how big the C ecosystem is.

I'm definitely aware that the C ecosystem is much larger than the Rust ecosystem.

replies(1): >>44459125 #
1. uecker ◴[] No.44459125[source]
I also doesn't seem like anything most people would spend a lot of time on. I run my tests using "make" which somewhat poor but does the job. So from a programming side, what exactly do you think would be difficult to implement in C?
replies(1): >>44459517 #
2. sunshowers ◴[] No.44459517[source]
> I also doesn't seem like anything most people would spend a lot of time on.

That's because the conditions created by C make solving this problem very hard, not because the problem isn't worth solving.

It is still a hard problem with Rust, requiring heavy use of async state machines to manage a rather extraordinary level of complexity. But at least it is possible for essentially a solo dev like myself to do in a robust, largely bug-free manner.

> I run my tests using "make" which somewhat poor but does the job.

Right, "make" is indeed not quite a high-performance enterprise-grade test runner with parallel test execution, high-quality reporting, signal handling, dynamic status querying, timeouts, retries, flaky test detection, mutual exclusion between tests, a DSL that lets you specify sets of tests, flexible configuration, archiving tests to run on another computer, sharding test runs, JUnit support, wrapper scripts, setup scripts, and several other features. Make doesn't even properly support Windows, which is table stakes for a portable test runner.

You're welcome to peruse the design documents:

https://nexte.st/docs/design/architecture/runner-loop/ (already linked above)

https://nexte.st/docs/design/architecture/signal-handling/

https://nexte.st/docs/design/architecture/input-handling/