←back to thread

Introducing tmux-rs

(richardscollin.github.io)
857 points Jtsummers | 10 comments | 03 Jul 25 15:03 UTC | HN request time: 0.234s | source | bottom
Show context
mbreese ◴[03 Jul 25 15:19 UTC] No.44455951[source]▶
> 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.

replies(15): >>44456003 #>>44456205 #>>44456799 #>>44457023 #>>44457048 #>>44457108 #>>44457783 #>>44458165 #>>44458298 #>>44458461 #>>44459018 #>>44459396 #>>44459476 #>>44459885 #>>44463066 #
1. nisegami ◴[03 Jul 25 15:43 UTC] No.44456205[source]▶
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

replies(3): >>44456243 #>>44456244 #>>44457407 #
2. miroljub ◴[03 Jul 25 15:47 UTC] No.44456243[source]▶
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.

replies(4): >>44456531 #>>44456600 #>>44456731 #>>44456941 #
3. Jtsummers ◴[03 Jul 25 15:47 UTC] No.44456244[source]▶
It's a transliteration. He's basically implemented a C program in Rust. He says in the conclusion the next goal is converting it to safe Rust.
4. Ar-Curunir ◴[03 Jul 25 16:12 UTC] No.44456531[source]▶
It’s just because there are a lot of unsafes, and because the translation from C to Rust introduced semantic-mismatch bugs
5. a_humean ◴[03 Jul 25 16:18 UTC] No.44456600[source]▶
They wrote everything in unsafe rust where its very possible to segfault. This is not a normal C to Rust port. In a normal port you would never aim to have 100% unsafe rust code - rather you would hive off small parts of your application where you need unsafe so its highlighted and auditable. This is clearly an excerise for fun.
replies(1): >>44458331 #
6. antonvs ◴[03 Jul 25 16:30 UTC] No.44456731[source]▶
No, the issue is that doing a direct translation from a fundamentally unsafe language like C can't fix safety issues.

You'd have to do a proper rewrite, in which case you could write safe code from the start.

> Every new project is bound to have bugs that need to be ironed out during the time.

Not on the level of the kind of critical security and reliability bugs that unsafe languages foster. That's why CISA and the FBI both strongly recommend memory-safe languages.

7. QuaternionsBhop ◴[03 Jul 25 16:47 UTC] No.44456941[source]▶
My understanding is that the author was referring to there being more segfaults in programming than in gardening.
replies(1): >>44456976 #
8. nicce ◴[03 Jul 25 16:50 UTC] No.44456976{3}[source]▶
Both can be true at the same time in that sentence
9. ar_lan ◴[03 Jul 25 17:37 UTC] No.44457407[source]▶
In the second sentence he mentions:

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

10. nicoburns ◴[03 Jul 25 19:20 UTC] No.44458331{3}[source]▶
I think it is a normal porting process, it's just only half-finished at this point. The conversion to safe Rust is yet to come.