←back to thread

Introducing tmux-rs

(richardscollin.github.io)
857 points Jtsummers | 2 comments | 03 Jul 25 15:03 UTC | HN request time: 0.41s | source
Show context
denysvitali ◴[03 Jul 25 15:41 UTC] No.44456180[source]▶
I like the initiative, but all this effort for ... unsafe Rust? I know it's a hot topic, and I hope the end goal is to have a memory-safe (and faster) tmux. I just hope the author doesn't stop here :)

Edit: As pointed out below, I'm stupid, it's stated in the article and I didn't read that part

replies(4): >>44456190 #>>44456251 #>>44456299 #>>44456452 #
1. riskable ◴[03 Jul 25 15:52 UTC] No.44456299[source]▶
It's the first step in a two-step process:

    1. Rewrite in (unsafe) Rust.
    2. Update the code over time, moving towards safe Rust.
It's the old, "get it working then fix it" process. In business that's normally a bad idea because you end up wasting more time than if you'd just done things correctly from the start but for a hobby project it's fine. Because then you're more likely to learn something and possibly—ultimately—end up with a better end product.

To a business, time your developers spend learning things (the hard way) is wasted.

To a hobbyist, taking the time to learn things is time well-spent.

replies(1): >>44456326 #
2. Jtsummers ◴[03 Jul 25 15:55 UTC] No.44456326[source]▶
In business it can also be a good idea, because if you're waiting for it to be done correctly you may never have a delivered product even if you have a working (but not 100% ideal) product. A compromise is to get a subset of your target capabilities working correctly and the rest unimplemented and deliver that before continuing on.