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.
Edit: apparently it did turn out to be a lot of unsafe code
Every new project is bound to have bugs that need to be ironed out during the time.
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.
interesting, I'm new to rust. what are you doing that necessitates using unsafe?
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.
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.
> 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.
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.
Or copies of old things apparently.
[1] jhawthorn/fzy: :mag: A simple, fast fuzzy finder for the terminal https://share.google/TBp3pVaFngBTfaFyO
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/helper... [2] https://github.com/Tombert/rs-fzf-clone/blob/main/src/proces...
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
I treat projects differently if they want to launch a product, they want to replace an established open source tool, done for fun for themselves, or if it’s a hobby project.
But tmux isn't new
Is a reason necessarily needed to rewrite software in other languages
Follow up questions are totally cool but the context is different, right?
If it isn't acceptable then there's a negative tone and questions are focused on utility and usually them "trying to help you" find utility.
If it is acceptable they ask you about your interests and what you're learning. Sometimes that can turn into utility but that's more natural.
It's a lot about culture to be honest. Some people are just toxic and if things don't make sense in their heads then it doesn't make sense in any head.
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.
In C you only see the flags people know of or remembered to plant. There's an awful lot of mines left unflagged and sometimes you step on them.
It's very obvious to me which would be more safe and I find myself questioning why it is isn't so obvious to others.
other people use the stupidest possible javascript to launch product and really focus on product and marketing
yet other people stay as far away from computers as possible and focus on more human activities
you just do what you're drawn to naturally
And assuming speed is not an issue, why would Rust make it better?
For command line tools I just appreciate if they're as fast as possible. And rg, fd, etc just show that Rust implementations can be correct and fast.
jesus christ, you’re not light yagami—please stay on /g/
Screen, tmux, byobu, dvtm, mtm, Twin, and most of all Zellij, which is basically "tmux but redone in Rust".
I tried to compare them all a month ago:
https://www.theregister.com/2025/06/24/tiling_multiplexers_s...
Crazy. They have gotten quite a lot of upvotes, for the record, but feel free to flag ALL of my comments.
I wonder what is so wrong about asking if I cannot chuckle anymore, so wrong that it warrants it to be flagged.
>> chuckles (written by me)
> jesus christ, you’re not light yagami—please stay on /g/ (written by some individual)
However, is not flagged. It would be hilarious if it was not so sad.
- persistence of layouts. Screen doesn't remember if you had a split view open, it always opens the current terminal in full screen.
- screen's default hotkey ^A clashes with ssh's escape key. Yes, these are configurable but having to re-populate the same config file is like a papercut every time to access a new system.
Defaults matter, especially if you work across many different systems (and from different customers). At some point, it just becomes easier to learn the defaults than to (over-)optimize to your ideal workflow.