7 ms·

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

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

sherburt3 1y ago
I was about to post a snarky comment because I have a knee jerk reaction whenever someone implies a rust application is intrinsically better than C. Sometimes I forget people do things for fun.
upmind 1y ago
I found out that quite funny, I wonder how many hours he spent on this. It seems extremely monotonous haha
- deleted 1y ago
  [deleted]
- ziml77 1y ago
  Sometimes that's exactly what one needs. As long as there's not forced schedule for the work and you can do it when you want and at the pace that you want, it can feel good.
- phkahler 1y ago
  I think knitting looks monotonous, but I can see the appeal.
nisegami 1y ago
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
- miroljub 1y ago
  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.
  - Ar-Curunir 1y ago
    It’s just because there are a lot of unsafes, and because the translation from C to Rust introduced semantic-mismatch bugs
  - a_humean 1y ago
    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.
    - nicoburns 1y ago
      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.
  - antonvs 1y ago
    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.
  - QuaternionsBhop 1y ago
    My understanding is that the author was referring to there being more segfaults in programming than in gardening.
cultofmetatron 1y ago
> Like gardening, but with more segfaults. interesting, I'm new to rust. what are you doing that necessitates using unsafe?
- tshaddox 1y ago
  I suspect it's vastly easier to port C to unsafe Rust than to safe Rust.
- jeroenhd 1y ago
  A lot of things that C will let you do (even if you enter the realm of undefined behaviour) will simply not compile to C. As the author states, there are semantic differences between pointers and Rust's references. C pointers can have as many owners as you want, may be subjected to mathematical operations, and can be cast to any type without even an error message. The compiler will just assume you know what you're doing. If you enable enough compiler warnings, it might warn you, but C compilers don't generate a lot of those by default. Rust will let you only generate one mutable (exclusive) reference at a time. This means straight C to Rust ports simply don't compile. By switching to pointers, which work pretty much like their C equivalent, you can port the code much easier, but you do of course lose the benefits of Rust's safety mechanisms, because most pointer operations throw away all the safety guarantee that Rust provides.
  - SoftTalker 1y ago
    So what is the advantage of an unsafe Rust implementation? Just to have done it?
    - cuu508 1y ago
      From the article: "The next goal is to convert the codebase to safe Rust."
    - petrzjunior 1y ago
      It is rewritten to a different language and many people find Rust easier to read, it has better type hint support for IDE etc. Also, you do not lose all the safety, there are still many rules enforced, such as safe linking, no undefined functions. Unsafe Rust means that all parts of code which do illegal pointer magic are explicitly marked with an "unsafe" keyword. You can now go one by one and fix them.
planet36 1y ago
"Gardening is the handiest excuse for being a philosopher." - Ray Bradbury, Dandelion Wine
vpShane 1y ago
> You might be asking: No, not at all. Rewrite all the things in Rust. if you enjoy it, do it. It leads to learning and learning leads to new innovation. If you enjoy making it in Rust, then I'll enjoy trying it out.
tombert 1y ago
Completely agree. Not every project has to be out there to change the world. I recently rewrote `fzf` [1] in Rust. Did I have any particular reason to do so? No, not really, regular `fzf` is fine, but I thought it would be a fun excuse to learn how fuzzy search algorithms work and how to exploit the channels in Rust. It was fun. There's no question that regular fzf is better but that wasn't the point, the point was to play with stuff and learn. [1] https://github.com/Tombert/rs-fzf-clone https://github.com/Tombert/rs-fzf-clone
- carlmr 1y ago
  Nice, I do think fzf is a really good candidate for something that could be better if written in Rust. The fzy[1] C-rewrite is really fast, but I couldn't get it to give me as useful results when searching bash history. [1] jhawthorn/fzy: :mag: A simple, fast fuzzy finder for the terminal https://share.google/TBp3pVaFngBTfaFyO https://share.google/TBp3pVaFngBTfaFyO
  - tombert 1y ago
    Yeah, I think Rust makes some sense, and I do think I've done a few clever things like getting a linear-time "sort" by exploiting the fact that there's a discrete and finite number of "scores" [1], and avoiding copies by taking the indexed values and explicitly moving them into the source channel to avoid extra copies [2]. Someone smarter than me who is more familiar with TUI programming could almost certainly augment and improve what I wrote; I worked on it for as long as it was interesting to me. I use it for my home-built program launcher thing Sway, though most people would probably get better results with real fzf. [1] https://github.com/Tombert/rs-fzf-clone/blob/main/src/helpers.rs#L54 https://github.com/Tombert/rs-fzf-clone/blob/main/src/helper... [2] https://github.com/Tombert/rs-fzf-clone/blob/main/src/processors.rs#L359 https://github.com/Tombert/rs-fzf-clone/blob/main/src/proces...
  - ricardobeat 1y ago
    First time hearing anyone say fzf can be slow. I mostly use it for filtering relatively small lists (few K items), for example git reflogs, is speed an issue when searching the whole filesystem or something on these lines? And assuming speed is not an issue, why would Rust make it better?
rauli_ 1y ago
Not every code project needs to turn out to be world changing. Experiments like this sometimes produce excellent results.
dsp_person 1y ago
Looking forward to the tmux-c re-rewrite next
- johnisgood 1y ago
  [flagged]
godelski 1y ago
Honestly, I often hate how people ask "why?", and don't understand how "for fun" is a legitimate answer. I get it for work or other things, but hobbies? We do lots of things for fun! Humans were born to play, just like every other animal. It's how we learn and explore the world around us. And frankly, to quote Knuth > In fact what I would like to see is thousands of computer scientists let loose to do whatever they want. That's what really advances the field. This is true for any field, or any project. We're creative creatures. We dream and explore. Major changes almost never come from doing things the way they've always been done. A lot of times "just because" gives you the freedom to try new things and challenge those paradigms. Weirdly, if you always have to justify everything you slow down progress.
- Arisaka1 1y ago
  I still believe that my #1 think that stunted my growth as a junior SWE was overthinking my personal projects and languages to use for them, instead of just building whatever I felt it's interesting or intriguing to build.
  - godelski 1y ago
    It's always hard to tell. But have you considered you might be measuring the wrong way? To me it sounds like you learned a real important lesson one that some people never seem to learn. I think one of the most beneficial aspects of doing things "just because" is these other skills or information you get along the way. It is very easy to miss all of this progress if you're too focused on the progress of the more tangible things. But that doesn't make any of that not progress. So don't put yourself down for that, because I'm sure you learned a lot. The only reason you can look back and see a better way is because you made that progress and learned those lessons. These are things mentors can usually help you get through faster but not everyone has a mentor nor access to one. But don't undermine your own progress just because you didn't finish projects or because you did things differently than others
  - ku1ik 1y ago
    Same here!
badgersnake 1y ago
> new things Or copies of old things apparently.
90s_dev 1y ago
Intuition and logic are the two halfs of reason (logos). We sometimes have a reason that we can't put into words (logos) but we know intuitively.
deleted 1y ago
[deleted]
1vuio0pswjnm7 1y ago
"We don't necessarily need a reason to build new things." But tmux isn't new Is a reason necessarily needed to rewrite software in other languages
- fragmede 1y ago
  GNU screen would like a word.
  - magarnicle 1y ago
    I really don't know how tmux got so much mindshare over screen. It just isn't obviously better in any way. Maybe screen is just poorly named?
    - usef- 1y ago
      I think a lot of it is that tmux had friendler, sane defaults and clearer command design (eg. status bar out of the box). And, I suspect, people not already knowing screen. The latter reason is why Helix is slow in doing similar to vim, I think, despite being far more consistently designed and saner defaults. Everyone knows vim exists. I've still never switched from screen, personally, though I'm only a light user.
      - quotemstr 1y ago
        > status bar out of the box Software packages win over other packages for the silliest reasons.
        vaylian 1y ago
        Defaults matter. I've had my screenrc with a status line but I still ended up preferring tmux in the end, because not needing a config file was a small but pleasant advantage when working with different machines. I also didn't like ctrl+a as the leader combination, because it conflicts with "go to the beginning of the line" in bash. ctrl+b is a much nicer default.
deleted 1y ago
[deleted]

sherburt3 1y ago

I was about to post a snarky comment because I have a knee jerk reaction whenever someone implies a rust application is intrinsically better than C. Sometimes I forget people do things for fun.

upmind 1y ago

I found out that quite funny, I wonder how many hours he spent on this. It seems extremely monotonous haha

deleted 1y ago
[deleted]
ziml77 1y ago
Sometimes that's exactly what one needs. As long as there's not forced schedule for the work and you can do it when you want and at the pace that you want, it can feel good.
phkahler 1y ago
I think knitting looks monotonous, but I can see the appeal.

nisegami 1y ago

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

miroljub 1y ago
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.
- Ar-Curunir 1y ago
  It’s just because there are a lot of unsafes, and because the translation from C to Rust introduced semantic-mismatch bugs
- a_humean 1y ago
  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.
  - nicoburns 1y ago
    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.
- antonvs 1y ago
  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.
- QuaternionsBhop 1y ago
  My understanding is that the author was referring to there being more segfaults in programming than in gardening.

cultofmetatron 1y ago

> Like gardening, but with more segfaults. interesting, I'm new to rust. what are you doing that necessitates using unsafe?

tshaddox 1y ago
I suspect it's vastly easier to port C to unsafe Rust than to safe Rust.
jeroenhd 1y ago
A lot of things that C will let you do (even if you enter the realm of undefined behaviour) will simply not compile to C. As the author states, there are semantic differences between pointers and Rust's references. C pointers can have as many owners as you want, may be subjected to mathematical operations, and can be cast to any type without even an error message. The compiler will just assume you know what you're doing. If you enable enough compiler warnings, it might warn you, but C compilers don't generate a lot of those by default. Rust will let you only generate one mutable (exclusive) reference at a time. This means straight C to Rust ports simply don't compile. By switching to pointers, which work pretty much like their C equivalent, you can port the code much easier, but you do of course lose the benefits of Rust's safety mechanisms, because most pointer operations throw away all the safety guarantee that Rust provides.
- SoftTalker 1y ago
  So what is the advantage of an unsafe Rust implementation? Just to have done it?
  - cuu508 1y ago
    From the article: "The next goal is to convert the codebase to safe Rust."
  - petrzjunior 1y ago
    It is rewritten to a different language and many people find Rust easier to read, it has better type hint support for IDE etc. Also, you do not lose all the safety, there are still many rules enforced, such as safe linking, no undefined functions. Unsafe Rust means that all parts of code which do illegal pointer magic are explicitly marked with an "unsafe" keyword. You can now go one by one and fix them.

planet36 1y ago

"Gardening is the handiest excuse for being a philosopher." - Ray Bradbury, Dandelion Wine

vpShane 1y ago

> You might be asking: No, not at all. Rewrite all the things in Rust. if you enjoy it, do it. It leads to learning and learning leads to new innovation. If you enjoy making it in Rust, then I'll enjoy trying it out.

tombert 1y ago

Completely agree. Not every project has to be out there to change the world. I recently rewrote `fzf` [1] in Rust. Did I have any particular reason to do so? No, not really, regular `fzf` is fine, but I thought it would be a fun excuse to learn how fuzzy search algorithms work and how to exploit the channels in Rust. It was fun. There's no question that regular fzf is better but that wasn't the point, the point was to play with stuff and learn. [1] https://github.com/Tombert/rs-fzf-clone https://github.com/Tombert/rs-fzf-clone

carlmr 1y ago
Nice, I do think fzf is a really good candidate for something that could be better if written in Rust. The fzy[1] C-rewrite is really fast, but I couldn't get it to give me as useful results when searching bash history. [1] jhawthorn/fzy: :mag: A simple, fast fuzzy finder for the terminal https://share.google/TBp3pVaFngBTfaFyO https://share.google/TBp3pVaFngBTfaFyO
- tombert 1y ago
  Yeah, I think Rust makes some sense, and I do think I've done a few clever things like getting a linear-time "sort" by exploiting the fact that there's a discrete and finite number of "scores" [1], and avoiding copies by taking the indexed values and explicitly moving them into the source channel to avoid extra copies [2]. Someone smarter than me who is more familiar with TUI programming could almost certainly augment and improve what I wrote; I worked on it for as long as it was interesting to me. I use it for my home-built program launcher thing Sway, though most people would probably get better results with real fzf. [1] https://github.com/Tombert/rs-fzf-clone/blob/main/src/helpers.rs#L54 https://github.com/Tombert/rs-fzf-clone/blob/main/src/helper... [2] https://github.com/Tombert/rs-fzf-clone/blob/main/src/processors.rs#L359 https://github.com/Tombert/rs-fzf-clone/blob/main/src/proces...
- ricardobeat 1y ago
  First time hearing anyone say fzf can be slow. I mostly use it for filtering relatively small lists (few K items), for example git reflogs, is speed an issue when searching the whole filesystem or something on these lines? And assuming speed is not an issue, why would Rust make it better?

rauli_ 1y ago

Not every code project needs to turn out to be world changing. Experiments like this sometimes produce excellent results.

dsp_person 1y ago

Looking forward to the tmux-c re-rewrite next

johnisgood 1y ago
[flagged]

godelski 1y ago

Honestly, I often hate how people ask "why?", and don't understand how "for fun" is a legitimate answer. I get it for work or other things, but hobbies? We do lots of things for fun! Humans were born to play, just like every other animal. It's how we learn and explore the world around us. And frankly, to quote Knuth > In fact what I would like to see is thousands of computer scientists let loose to do whatever they want. That's what really advances the field. This is true for any field, or any project. We're creative creatures. We dream and explore. Major changes almost never come from doing things the way they've always been done. A lot of times "just because" gives you the freedom to try new things and challenge those paradigms. Weirdly, if you always have to justify everything you slow down progress.

Arisaka1 1y ago
I still believe that my #1 think that stunted my growth as a junior SWE was overthinking my personal projects and languages to use for them, instead of just building whatever I felt it's interesting or intriguing to build.
- godelski 1y ago
  It's always hard to tell. But have you considered you might be measuring the wrong way? To me it sounds like you learned a real important lesson one that some people never seem to learn. I think one of the most beneficial aspects of doing things "just because" is these other skills or information you get along the way. It is very easy to miss all of this progress if you're too focused on the progress of the more tangible things. But that doesn't make any of that not progress. So don't put yourself down for that, because I'm sure you learned a lot. The only reason you can look back and see a better way is because you made that progress and learned those lessons. These are things mentors can usually help you get through faster but not everyone has a mentor nor access to one. But don't undermine your own progress just because you didn't finish projects or because you did things differently than others
- ku1ik 1y ago
  Same here!

badgersnake 1y ago

> new things Or copies of old things apparently.

90s_dev 1y ago

Intuition and logic are the two halfs of reason (logos). We sometimes have a reason that we can't put into words (logos) but we know intuitively.

deleted 1y ago

[deleted]

1vuio0pswjnm7 1y ago

"We don't necessarily need a reason to build new things." But tmux isn't new Is a reason necessarily needed to rewrite software in other languages

fragmede 1y ago
GNU screen would like a word.
- magarnicle 1y ago
  I really don't know how tmux got so much mindshare over screen. It just isn't obviously better in any way. Maybe screen is just poorly named?
  - usef- 1y ago
    I think a lot of it is that tmux had friendler, sane defaults and clearer command design (eg. status bar out of the box). And, I suspect, people not already knowing screen. The latter reason is why Helix is slow in doing similar to vim, I think, despite being far more consistently designed and saner defaults. Everyone knows vim exists. I've still never switched from screen, personally, though I'm only a light user.
    - quotemstr 1y ago
      > status bar out of the box Software packages win over other packages for the silliest reasons.
      - vaylian 1y ago
        Defaults matter. I've had my screenrc with a status line but I still ended up preferring tmux in the end, because not needing a config file was a small but pleasant advantage when working with different machines. I also didn't like ctrl+a as the leader combination, because it conflicts with "go to the beginning of the line" in bash. ctrl+b is a much nicer default.

deleted 1y ago

[deleted]