[HN Gopher] Introducing tmux-rs
___________________________________________________________________
Introducing tmux-rs
Author : Jtsummers
Score : 519 points
Date : 2025-07-03 15:03 UTC (7 hours ago)
(HTM) web link (richardscollin.github.io)
(TXT) w3m dump (richardscollin.github.io)
| mbreese wrote:
| _> 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.
| upmind wrote:
| I found out that quite funny, I wonder how many hours he spent
| on this. It seems extremely monotonous haha
| ziml77 wrote:
| 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 wrote:
| I think knitting looks monotonous, but I can see the appeal.
| nisegami wrote:
| 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 wrote:
| 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 wrote:
| It's just because there are a lot of unsafes, and because
| the translation from C to Rust introduced semantic-mismatch
| bugs
| a_humean wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| My understanding is that the author was referring to there
| being more segfaults in programming than in gardening.
| nicce wrote:
| Both can be true at the same time in that sentence
| Jtsummers wrote:
| 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.
| ar_lan wrote:
| 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.
| cultofmetatron wrote:
| > Like gardening, but with more segfaults.
|
| interesting, I'm new to rust. what are you doing that
| necessitates using unsafe?
| tshaddox wrote:
| I suspect it's vastly easier to port C to unsafe Rust than to
| safe Rust.
| jeroenhd wrote:
| 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 wrote:
| So what is the advantage of an unsafe Rust implementation?
| Just to have done it?
| cuu508 wrote:
| From the article: "The next goal is to convert the
| codebase to safe Rust."
| petrzjunior wrote:
| 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.
| kevincox wrote:
| Once the codebase is all Rust you can start introducing
| Rust idioms and patterns. Basically step 1 is to get it
| working in Rust then step 2 is to clean up the Rust to
| actually take advantage of the language.
| zozbot234 wrote:
| > Rust will let you only generate one mutable (exclusive)
| reference at a time.
|
| Safe Rust includes many forms of shared mutability,
| including Cell<> which is perhaps the closest comparison to
| typical patterns in C code.
| krater23 wrote:
| Hmm...I like when the compiler don't steps in my way and
| assumes that I know what I'm doing. Thats the reason why I
| don't like Rust. But when you like it, have fun!
| anyfoo wrote:
| "Hmm...I like when the assembler don't steps in my way
| and assumes that I know what I'm doing. Thats the reason
| why I don't like C, and prefer assembler. But when you
| like it, have fun!"
| planet36 wrote:
| "Gardening is the handiest excuse for being a philosopher." -
| Ray Bradbury, Dandelion Wine
| tombert wrote:
| 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
| carlmr wrote:
| 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
| tombert wrote:
| 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/helper... [2]
| https://github.com/Tombert/rs-fzf-
| clone/blob/main/src/proces...
| rauli_ wrote:
| Not every code project needs to turn out to be world changing.
| Experiments like this sometimes produce excellent results.
| dsp_person wrote:
| Looking forward to the tmux-c re-rewrite next
| johnisgood wrote:
| These people are delusional, leave them be. :D
| godelski wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Same here!
| serial_dev wrote:
| Asking "why" can still be a legitimate question, and "for
| fun" can also be a legitimate answer.
|
| 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.
| charcircuit wrote:
| There is more than 1 way to have fun. Some ways of having fun
| will produce more value to other people than others.
| badgersnake wrote:
| > new things
|
| Or copies of old things apparently.
| 90s_dev wrote:
| 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.
| 1vuio0pswjnm7 wrote:
| "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 wrote:
| GNU screen would like a word.
| df0b9f169d54 wrote:
| tmux has been used a lot of memory on my system, especially when
| scrolling buffer is large enough (I often have > 10k lines of
| things ).
|
| I have often executed `pkill -9 tmux` and saved my day. I hope
| the rust version can help a bit here?
| downrightmike wrote:
| Let us know
| throwaway290 wrote:
| Tmux has configurable scrollback buffer size, maybe set-option
| -g history-limit something-smaller in your config?
| 01HNNWZ0MV43FF wrote:
| How much is a lot? Even 10,000 lines of text should be on the
| order of megabytes, right?
| denysvitali wrote:
| 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
| verbatim wrote:
| At the end of the article he states that the next step is to
| work toward safe Rust.
| denysvitali wrote:
| Thank you! I skimmed through the article and didn't find
| this. Should have used CTRL+F :)
| johnisgood wrote:
| I highly doubt it is going to happen. Should have started
| from scratch, in Rust.
| riskable wrote:
| 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.
| Jtsummers wrote:
| 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.
| busterarm wrote:
| It's not exactly a stupid thought. My immediate reaction was:
| 1) 25% more LOC, 2) in unsafe Rust, 3) for a tool that already
| has great maintainence.
|
| The only reason this is at the top of HN is because of where
| Rust is on the Gartner Hype Cycle right now.
|
| It's neat, but I wouldn't say useful.
| tialaramex wrote:
| Coincidentally I was just watching this, "Oxidise Your Command
| Line"
|
| https://www.youtube.com/watch?v=rWMQ-g2QDsI
|
| Some of that video is about stuff you have no use for if you're
| not a Rust developer, but, some of it is things that would be
| just as useful to anybody who is comfortable with, as it says, a
| command line interface.
| alexvitkov wrote:
| I'll take a rust tmux if it runs on Windows. I'm currently kind
| of stuck on Windows and I didn't realize how much tmux means to
| me until Bill took it away :(
| throwaway290 wrote:
| Why are you stuck on Windows?
| diggan wrote:
| Some programs only run on Windows, this isn't a new problem.
| Personally, the only reason I have a Windows installation on
| my desktop is because Ableton doesn't run (well) via Wine, so
| not a lot of options really.
| vunderba wrote:
| This. DAW support in Linux has always been kind of rough.
| It's slowly getting better though with stuff like Bitwig
| and Reaper.
| finnjohnsen2 wrote:
| At least he's not stuck on MacOS
| mystifyingpoi wrote:
| Most people in big companies are stuck with Windows. But WSL2
| is really amazing, even if a workaround in idea.
| joe_guy wrote:
| tmux runs fine in WSL1/2
| nickjj wrote:
| Yep I've been doing this since WSL 1 was available, it's rock
| solid.
|
| My dotfiles at https://github.com/nickjj/dotfiles have an
| install script to automatically get everything (including
| tmux w/ plugins) set up on Debian, Ubuntu, Arch Linux or
| macOS. This includes native Linux and WSL 2 support.
| alexvitkov wrote:
| WSL is not Windows. Unless you can work entirely in WSL (and
| if I could I'd just use Linux) having to juggle fake
| filesystems, incompatible symlinks, two PATHs, three shells
| is a bit much.
| submeta wrote:
| Tmux is a gamechanger for me. Being able to start a dozen
| different projects with one line (using tmuxinator): the server,
| tailing logfiles, activating venvs, running the docker container,
| all within one line of code: Awesome. Hadn't worked with it for
| years, just started again two days ago as I migrated from iTerm
| to Ghostty. And am loving the setup. Plus nvim. Pure awesomeness.
|
| Looking forward to check out tmux-rs.
| kccqzy wrote:
| Surprised to hear you migrated from iTerm. It actually has a
| tmux integration mode (using -CC) that's awesome. You then
| don't have to remember any tmux specific shortcuts. Switching
| window is just Cmd+` just like everywhere else.
|
| I entirely stopped using tmux when I couldn't use iTerm.
| johnisgood wrote:
| > Looking forward to check out tmux-rs.
|
| Have you checked out the website? This is a c2rust project. The
| Rust code is full of unsafe code and probably buggier than the
| C version, and let us not even mention readability and
| maintainability. Maybe there is a joke somewhere.
| neuspadrin wrote:
| Did you? Like 2 paragraphs in:
|
| > I threw away all of the C2Rust output and decided I would
| translate all of the files into Rust manually from C.
|
| The talk about starting with it, realizing it was too rough
| and changed approach. It's unsafe rust now but next goal at
| end was a safe version.
| johnisgood wrote:
| Yeah, time will tell. I am not going to hold my breath. You
| can, but you might find yourself dead (or not, actually).
|
| Have you read the conclusion, BTW?
| johnisgood wrote:
| To all the down-voters: worth reading:
| https://news.ycombinator.com/item?id=44459114
| uecker wrote:
| 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....
| perching_aix wrote:
| This reminded me of no-code:
| https://github.com/kelseyhightower/nocode
| antonvs wrote:
| > But otherwise, maybe better not rewrite working code....
|
| Except that the eventual result allows for extension and
| improvements in a memory-safe language.
| uecker wrote:
| There seems to be some rather irrational obsession about
| this.
| antonvs wrote:
| 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.
| uecker wrote:
| 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.
| antonvs wrote:
| There's a lot of subjectivity here. The last serious C
| code I wrote was in the early 1990s, and I don't miss it
| at all, because I don't like spending time on low-level
| details unrelated to the problem domain I'm working on.
|
| I find Rust fun and easy for writing system-level code,
| and I have enormous appreciation for the degree of
| correctness-by-construction that it can provide.
| Generally, if it builds, it works, as long as you're
| making proper use of the type system - make illegal
| states unrepresentable, as the saying goes. That's very
| difficult to do with C.
|
| Rust isn't perfect. For most things, I'd rather be using
| Haskell, ML, or something on that level. But it's still
| on a completely different level from C, and rewriting the
| software ecosystem in it can only be an improvement.
| davemp wrote:
| C23 is very different than C89. C89 variable declarations
| are decidedly not fun.
|
| Embed, designated initialization, and constexpr are
| really nice adds.
| nicce wrote:
| > It is also less fun
|
| Statistically it is the most fun language there is, based
| on Stackoverflow. Portability is just a matter of time
| like with any language.
| uecker wrote:
| Lol, if you believe such surveys.
| krater23 wrote:
| It's fun when you don't use it for work. And the most
| people don't use it for work but just rewrite any tool
| they can find.
| sunshowers wrote:
| 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/
| uecker wrote:
| 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.
| sunshowers wrote:
| 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.
| uecker wrote:
| 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?
| sunshowers wrote:
| > 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/
| krater23 wrote:
| Looks like you think only in windows and linux. Ok, but
| how much of your rust runs on freeRTOS or bare metal and
| on how many processor families? C? Runs on all of them.
| 6502? No Problem? 8051? Clearly! CRC16C? Yes. Eco32? yup.
| i386? Is developed to run C. Arm64, Arm? They too. They
| run Minix in their internal controlling hardware. Written
| in C...
|
| Rust is not portable at all compared with C code.
| sunshowers wrote:
| Nextest works on a variety of platforms and architectures
| -- a lot more than x86_64 Windows and Linux. Porting to
| new platforms tends to be quite straightforward as long
| as someone's made Tokio work on that platform. (This is
| the power of abstraction! Turning MxN portability
| problems into M+N ones.)
|
| C definitely has a place, but "Rust is not portable at
| all compared with C code" is simply not correct. A lot
| more Rust code works across Windows and Unix than C code
| does. Rust's portability story is different from C's,
| much better in many ways but worse in others. In practice
| I do think Rust ends up being more portable than C in
| most practical scenarios -- for example, look at how
| things like `eza` work on Windows, the number one
| developer platform worldwide.
| chillingeffect wrote:
| > developed in the 1970s.
|
| It was born in the 1970s and was standardized in the 80s
| and 90s. It continues to develop. Numerous data types
| have been added, along with unicode and threads. The C23
| standard was released last year.
| antonvs wrote:
| You can say something similar about COBOL and FORTRAN.
| C's fundamental flaws aren't being fixed, because that
| would require a new language.
|
| There comes a point at which it becomes necessary to move
| on.
| Spivak wrote:
| What in your mind are the fundamental issues of C?
| Because memory safety clearly isn't one of them as brand
| new systems languages are being written without it (Zig).
| steveklabnik wrote:
| Absolutely zero shade to Zig, because it is still
| pre-1.0, but if you look at which new systems languages
| have gained wide adoption recently, instead of languages
| that are just created, you end up with Rust. And the
| stated reason industry is adopting it is memory safety.
| cwood-sdf wrote:
| zig is trying its best to also be memory safe (at
| runtime, if you want it) whereas c is stuck in the past
| (you can add on sanitizers, but they arent built into the
| language)
| antonvs wrote:
| Memory safety is certainly a pretty fundamental problem
| with C. Zig actually addresses some of those issues, even
| if it's not fully "memory safe" by definition. Besides,
| the fact that new systems languages are being written
| without memory safety doesn't make it a good idea. People
| write all sorts of languages for all sorts of reasons.
|
| C's lack of memory safety covers a broad range of
| concerns, including manual memory management,
| unrestricted pointers, null pointers (Tony Hoare's
| "billion dollar mistake"), buffer overflows, use-after-
| free, integer promotions, and so on.
|
| Its weak type system is another fundamental limitation,
| closely related to its limited support for abstraction.
| The weakness of the standard library reflects this. The
| weak type system means that the static guarantees it
| provides are minimal. There were excuses for all this in
| 1975, there aren't any more.
|
| Undefined behavior is more of an issue in C than in most
| languages. Again, not something you ideally want in a
| systems language.
|
| Language-level concurrency support is virtually
| nonexistent.
|
| Use of textual preprocessing, with limited semantic
| integration, as a language feature. Aside from the
| effects on the meaning of source code, it also makes
| building C programs more complex.
|
| And again, the reason C23 hasn't addressed any of this
| significantly is because of fundamental limitations in
| the nature of the language. You can't "fix" these things
| without developing a new language.
| uecker wrote:
| I think this narrative of the unfixable fundamental flaws
| in C is a lot of nonsense. There are certainly a lot of
| dangerous aspects, but most are rather easily avoided.
| Rust has an advantage, with temporal memory safety. I do
| not think C++, Zig, or Go have a fundamental advantage.
| There is certainly a lot of bad C code out, but instead
| of changing language, you could also just write modern C
| code.
| donkeybeer wrote:
| What's wrong with FORTRAN?
| pklausler wrote:
| It's hard to actually define what Fortran means. There's
| features in the standard that are not portable, and many
| portable features that are not standard. It's kind of a
| mess, and getting worse.
| antonvs wrote:
| The same kinds of things that are wrong with all
| languages originally designed more than 50 years ago (75
| years in Fortran's case) and that have accreted features
| since then. You end up with long-term fads like class-
| based object orientation embedded in the language, and
| that inhibits them evolving towards more principled
| designs. C++ is in a similar situation.
|
| All of these languages are Turing complete. So
| ultimately, if you're happy writing code in some language
| and don't want to change, that's your choice. But the
| reason Fortran or C or C++ isn't many people's first
| choice for new projects are closely related to the
| reasons I've mentioned. There will always be people who
| want to stick to what they know, but it's not only
| science that advances one funeral at a time.
| wat10000 wrote:
| It comes from the fact that nearly every useful program
| written in C has multiple security vulnerabilities just
| waiting to be found. In the unlikely event that you have a
| codebase that's free of them, you risk introducing one with
| any significant change.
| JdeBP wrote:
| Instead of just dogmatically asserting that any C program
| has security vulnerabilities, and changing C programs is
| also a security problem, you should look at what tmux's
| record actually is.
|
| tmux has existed for approaching 18 years, and M.
| Marriott is still actively improving it as of last week.
| One can actually look at its record over that time, and,
| if that record is poor, replace proof by unsupported
| generalized assertion with proof based upon actual
| evidence.
|
| * https://cvedetails.com/product/20683/Nicholas-Marriott-
| Tmux....
| wat10000 wrote:
| That search misses this:
| https://www.cvedetails.com/cve/CVE-2020-27347/
|
| That is still quite a good record, but my statement
| stands. It is supported by decades of my experience
| working in C-derived languages. You don't have to accept
| my experience or believe my statement, of course, it's
| all the same to me.
| hnlmorg wrote:
| That's a little like closing the barn door after the
| horse has already bolted because if you're concerned
| about security, then running any untrusted software in
| your terminal multiplexer is already a bad idea,
| regardless of whether your multiplexer is written in a
| memory-safe language or not.
|
| ...and before someone moans that I'm a C-fanboy, I'm
| really not. I've been writing software exclusively in
| memory-safe languages for 10+ years now. But I'm also
| pragmatic about when arguments about a RiR (rewrite-in-
| rust) are sensible and when they're not. In tmux's
| specific case, arguing about security misses the point.
| ozgrakkurt wrote:
| As someone using rust for over 7 years and recently
| switched to zig for personal projects, there is a lot of
| nuance. Yes rust is very reliable, it is really good even
| if you set memory safety aspect aside. But developing in
| rust is just so painful compared to using a simple
| language like c or zig and just enjoying the process.
|
| Also dev time is massively shorter and the time I gain is
| spent on adding more features and tests.
|
| Would recommend building low level projects in something
| like zig, if you care about build time and don't want to
| use a dependency for everything.
| wat10000 wrote:
| I like C and various parts of C++ and I'm still writing
| new code in those languages. But for any component that
| could be exposed to malicious data, security is a never-
| ending game of whack-a-mole. I'm not saying everyone must
| move away, just that when people do, this is a big reason
| why.
| hnlmorg wrote:
| tmux doesn't really gain anything from memory safety because:
|
| 1. anything running in tmux already has execution rights and
| typically for the same user as tmux anyway.
|
| 2. Anyone who wanted to exploit tmux could just run 'tmux -C'
| and automatically get access to literally every interaction
| within tmux.
|
| 3. The software itself is already damn stable. I've never had
| it crash.
|
| If you're worried about someone exploiting your terminal then
| tmux is a terrible option, irrespective of whether it's with
| written in C or Rust. And I say this as someone who
| absolutely loves tmux and uses it every day.
|
| [edit]
|
| And if you're worried about non-security related bugs
| affecting UX, then a rewrite in any language, regardless of
| the language, is a worse solution if your application has
| already been battle-tested for close to two decades. You're
| much better off creating something entirely new instead of
| porting code from one language to another because at least
| then you have new ideas instead of the same application but
| with new bugs in different places.
|
| I don't say this because of some bias that Rust fanboys will
| assume I have. I love memory safe languages and think Rust is
| a great option for new projects. The point I'm making here is
| that a rewrite doesn't gain much for tmux SPECIFICALLY
| because tmux is already extremely stable.
| legobmw99 wrote:
| There are reasons to be worried about additional safety
| beyond just security. My first thought when reading the
| article was it would be a huge bummer if a bug in tmux
| brought down a long-running or particularly stateful
| session. Of course, I've never encountered such a thing in
| my own usage, but if you could make it less likely that
| alone seems like a value add
| hnlmorg wrote:
| If tmux was a new project then I'd agree with you. But,
| like yourself, I've using tmux for probably close to 15
| years now and never had it crash once.
|
| In fact the author of this project has admitted that
| they've introduced bugs with their rewrite. I know it's a
| hobby project so I'm not being critical of their work.
| But if we're only interested in reducing bugs then
| rewriting an existing project isn't the right way to go.
| Something like Zellij makes more sense because it's
| offering something new in addition to being written in
| Rust.
| antonvs wrote:
| Any program gains from memory safety. Memory safety is not
| just about security. It's about eliminating an entire class
| of bugs - buffer overflows, null pointer errors, use-after-
| free, the list goes on. They just so happen to be the kind
| of bugs that _also_ tend to have serious security
| consequences.
|
| I honestly don't get this relentless defense of 1970s-style
| programming. Do you think C is the pinnacle of programming
| language design? No? Then what's your point, exactly?
| hnlmorg wrote:
| > Any program gains from memory safety. Memory safety is
| not just about security. It's about eliminating an entire
| class of bugs - buffer overflows, null pointer errors,
| use-after-free, the list goes on. They just so happen to
| be the kind of bugs that also tend to have serious
| security consequences.
|
| Have you actually ever encountered such a bug in tmux
| though? Because I've been using it for around 15 years
| and can honestly say I haven't.
|
| Yet this rewrite _has_ introduced bugs. I know it 's a
| hobby project so I'm not being critical. But if you're
| just trying to reduce bugs then rewriting code battle
| tested code in another language, regardless of that
| language, isn't the right way to go.
|
| > I honestly don't get this relentless defense of
| 1970s-style programming. Do you think C is the pinnacle
| of programming language design? No? Then what's your
| point, exactly?
|
| Where was I defending 1970s style programming? I wasn't
| even defending C. In fact the last project I've worked on
| based in either C or C++ was 10 years ago. Believe me,
| I'm a fan of memory safe languages ;)
|
| My point was very clear and very specific to tmux. You're
| just trying to read between the lines and create a whole
| new argument where there was none.
| remram wrote:
| You forget that tmux is a terminal emulator. Trusted
| programs can have untrusted/attacker-controlled terminal
| output. If the program running inside tmux (e.g. cat, curl
| -s, weechat) can output malformed unicode or escape
| commands that trigger crashes or code execution, it is
| actually a huge problem.
| greenavocado wrote:
| This is funny, but unfortunately .NET went all in on the AI
| coding assistant kool-aid.
|
| https://github.com/dotnet/runtime/pull/115762
|
| https://github.com/dotnet/runtime/pull/115743
|
| https://github.com/dotnet/runtime/pull/115733
|
| https://github.com/dotnet/runtime/pull/115732
| tacker2000 wrote:
| Wow, so this MS dev is trying out Copilot on the dotnet repo
| and doesnt even configure it correctly beforehand?
|
| Or was that comment just a cop-out because Copilot's results
| were complete nonsense?
| teekert wrote:
| Nice, I like tmux, I use it daily, I live in it. I hope this
| version makes it easier to just scroll with the scroll wheel or
| ctrl-page-up/down, or ctrl tab through your panes, or just show
| the whole unconcatenated title in the bottom left ;)
|
| Sorry I know this is not the place to complain, but it would be
| so nice!
| jayknight wrote:
| For me scroll wheel just works. The other stuff wouldn't be
| hard to configure with `bind-key`. I use ctrl-space to cycle
| through panes in a window:
|
| bind-key -n C-Space select-pane -t +1
| 0x457 wrote:
| You might like zellij more than tmux.
| antonvs wrote:
| I use byobu which is basically an opinionated distribution of
| tmux. Scroll wheel works fine, as does Alt-PgUp/PgDn.
|
| Ctrl-Tab probably won't work because terminals tend not to
| recognize it as different from Tab. But you might be able to
| bind Alt-Tab or some other such combo to cycle through panes in
| the tmux config. It should just be a one-liner.
| psyclobe wrote:
| Oh neat!!
| ethagnawl wrote:
| This announcement has my attention.
|
| I've been working on a Rust-based tmux session manager called
| rmuxinator (i.e. tmuxinator clone) for a few years now. It
| (mostly) works and been slow going because ... life but I've
| recently picked it back up to fix some bugs. One of the last new
| features I'd added was the ability to use rmuxinator as a library
| in other Rust programs. I'd like to try forking tmux-rs, adding
| rmuxinator as a dependency and seeing if it would ... just work
| as a way to start sessions using per-project config files. I'm
| definitely not advocating for adding rmuxinator upstream but it
| would be very nice to have this sort of session templating baked
| into the "terminal multiplexer" itself.
|
| The other interesting possibility I could foresee is doing things
| the other way around and having rmuxinator use tmux-rs as a
| library in order to setup and manage sessions instead of just
| dumping out shell commands -- which is fraught with edge cases.
| (Not sure if this is currently possible with tmux-rs, though.)
|
| Once I wrap up the bugfixes I'm currently working on, I may fork
| this project and give one or both of the above a try.
|
| Regardless, nice work by richardscollin!
| echelon wrote:
| I wonder if the tmux maintainers would be interested in switching
| to this?
|
| Transitioning more software from C to Rust is a great idea.
| joshka wrote:
| Taking a look at the source earlier, I'd guess probably not.
|
| If you're going to move a project to rust, you'd want to
| actually make it look like rust. Currently it looks like C
| written in rust. That doesn't make anyone happy really.
|
| (Obv. not a slight on the maintainer here, it's a personal
| project with a specific approach)
| uecker wrote:
| It is a horrible idea.
| zppln wrote:
| Seems like a bit entitled to expect being able to go around
| rewriting stuff and then have the old maintainers maintain it.
| echelon wrote:
| > to expect
|
| I wonder, I don't expect.
|
| This would require first for the Rust implementation to grow
| beyond a POC with code translation. In its current state I
| doubt it could entice any of the original authors or
| maintainers. But if it became capable and hardened and picked
| up velocity, then it would pose some major questions for
| having two similar pieces of software.
| yjftsjthsd-h wrote:
| My understanding is that tmux is primarily an OpenBSD project,
| and rust isn't a good fit for them (for reasons that summarize
| to portability problems), so it is extremely unlikely. Also,
| this is a hobby project that currently is all unsafe, so
| there's not even any particular point. (EDIT: Of course, as it
| gets rewritten the latter point is likely to diminish)
| zozbot234 wrote:
| > rust isn't a good fit for them (for reasons that summarize
| to portability problems)
|
| These problems are largely solved now that there's a working
| transpiler from Rust to C -
| https://github.com/FractalFir/rustc_codegen_clr
| yjftsjthsd-h wrote:
| > This project is still early in its developement. Bugs,
| crashes and miscompilations are expected. DO NOT USE IT FOR
| ANYTHING SERIOUS.
|
| > rustc_codegen_clr is only tested on Linux x86_64, with
| the CoreCLR runtime (more commonly known as simply the .NET
| runtime), on .NET 8. It should work on other platforms, but
| it is not guaranteed.
|
| I guess it could eventually be an option, but _today_ it
| looks more like a neat tech demo.
| johnisgood wrote:
| Is this a joke? Have you seen the generated Rust code? This is
| not an actual rewrite.
| aniforprez wrote:
| Seems like you didn't read the article at all. The author
| talks about writing it themselves after finding the
| automatically generated code not up to snuff.
| johnisgood wrote:
| I did, but I am not having high hopes. Have you read the
| conclusion?
| johnisgood wrote:
| Oh please, kind down-voters, have a read:
|
| > https://github.com/richardscollin/tmux-rs/issues/9
|
| > 120 comments and nobody has mentioned the use-after-
| free triggered by closing a window. Rust truly is the
| safest language.
| rthnbgrredf wrote:
| This seems like an excellent future use case for a fully
| automated process by a large language model that translates a
| non-trivial C codebase to Safe Rust in under an hour with high
| accuracy. However, as the author noted, even after some attempts
| with Cursor at the end of development, the tool wasn't able to
| accelerate the translation effectively (in mid-2025). So while
| the potential is promising, it appears we're still some way off.
| gavmor wrote:
| These folks[0] are doing it, possibly via "codemods"[1], which
| utilize ASTs.
|
| 0. https://codemod.com/ 1.
| https://martinfowler.com/articles/codemods-api-refactoring.h...
| keybored wrote:
| > This seems like an excellent future use case for a fully
| automated process by a large language model that translates a
| non-trivial C codebase to Safe Rust in under an hour with high
| accuracy.
|
| That's specific.
| qwertywert_ wrote:
| You weren't really lying when you said "100% (unsafe) Rust" eh..
| lolive wrote:
| D.mn!
|
| I was hoping for the announcement of a brand new bulletproof
| tmux-resurrect.
|
| But no, it is (just) tmux-(recodedIn)rust.
| parhamn wrote:
| Interesting, this article and the comments make no mention of
| LLMs for the initial translation. Really surprising given that
| would be the first thing I'd reach for for a translation/porting
| task (though verification could get tricky).
|
| Now I really wonder how a good model like Sonnet 4 would have
| performed.
| TechDebtDevin wrote:
| It wouldnt have gotten 2% finishd. It wouldn't have compiled.
| Its a waste of time to even consider.
| parhamn wrote:
| > It wouldnt have gotten 2% finishd
|
| What do you mean by this? I'd assume the process would be
| very very incremental. One function + accompany tests at a
| time, verify and continue and keep moving up the tree.
|
| It's an interesting problem because I imagine in the future
| lots of things will be ported like this.
| TechDebtDevin wrote:
| You've been duped my friend.
|
| -edit Good luck reading 100k lines of Claude generated Rust
| that you know nothing about lol. LLMS are not the tool for
| this.
| dkdcio wrote:
| did you read the article? it does mention using LLMs
| Jtsummers wrote:
| > Interesting, this article and the comments make no mention of
| LLMs.
|
| https://richardscollin.github.io/tmux-rs/#ai-tools
| parhamn wrote:
| Using Cursor to refactor the unsafe code is quite a different
| task than using an LLM to translate into safe rust. I was
| just curious how it would perform.
| smj-edison wrote:
| Check the bottom :)
|
| > I did start trying out Cursor towards the end of the
| development process. I ended up stopping using it though
| because I felt like it didn't actually increase my speed. It
| only saved me from finger pain. 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.
| The only thing it saved was my hands. Doing this large amount
| of refactoring is really hard on your fingers.
| keybored wrote:
| The people demand the AI angle.
| xvilka wrote:
| Nice, hope it will become cleaner code in time. I tried zellij
| multiple times but despite years of development it still misses
| many things tmux provides. Inability to show/hide status bar[1]
| is the most annoying.
|
| [1] https://github.com/zellij-org/zellij/issues/694
| imbnwa wrote:
| You can't rebind key maps to its session manager plugin, making
| it a no-go since I bind the same key that the plugin uses to
| select a directory or something. Thus, I can't create new
| sessions through it, have to do it from the command line.
| tekawade wrote:
| I love this. I also want to dabble into loving things to rust!
|
| Here I want to call out zellij. Zellij is rust based terminal
| multiplexer.
|
| I am user not creator. I love everything rust and finding and
| migrating to rust based solutions where feasible.
| londons_explore wrote:
| LLM's are really good at translating one programming language
| into another.
|
| In fact, I sometimes port code to another language and back just
| as a way to do code cleanup (or at least give ideas for things
| that could be cleaned up)
|
| I wonder why OP didn't start from that as a starting point?
| lab14 wrote:
| Because he didn't want to? He mentioned that for him, this is
| like a "gardening" project, so why take away the joy of
| programming just to become an AI operator?
| Etheryte wrote:
| This is discussed in the article? They tried cursor, but the
| bug rate was no better than their manual effort, so at least in
| this context, it did not work out.
| z3ratul163071 wrote:
| rewriting old code in new language is the killer application for
| AI. should have used that instead of transpiler.
| someperson wrote:
| Surely improvements be made to c2rust to reduce the cited
| information loss with constant naming, to reduce the initial
| conversion burden?
| kevincox wrote:
| Yeah, this seems like a huge missing feature for C2Rust. IIUC
| the main idea is to serve as a base for then porting to
| idiomatic Rust. But if you lose all of the constants that is a
| huge productivity loss.
| dataking wrote:
| Indeed. We had experimental support for preserving (some)
| constants but it fell by the wayside. We're bringing it back
| in the coming months.
| johnisgood wrote:
| > the code base is now 100% (unsafe) Rust. I'd like to share the
| process of porting the original codebase from ~67,000 lines of C
| code to ~81,000 lines of Rust
|
| Sounds to me that this was a C -> Rust transpiler. :D
|
| Edit: I was right, they used c2rust.
|
| And then there is "// generated Rust code".
|
| As for the code snippets on
| https://richardscollin.github.io/tmux-rs/, I can read the C
| version better than the generated Rust code. //
| cmd-kill-session.c RB_FOREACH(wl, winlinks, &s->windows) {
| wl->window->flags &= ~WINDOW_ALERTFLAGS; wl->flags &=
| ~WINLINK_ALERTFLAGS; } // cmd_kill_session.rs
| for wl in rb_foreach(&raw mut (*s).windows).map(NonNull::as_ptr)
| { (*(*wl).window).flags &= !WINDOW_ALERTFLAGS;
| (*wl).flags &= !WINLINK_ALERTFLAGS; }
|
| Please let me know which one is more readable to you.
| jonpalmisc wrote:
| I don't think anyone is suggesting that the generated Rust is
| nicer than the original C.
|
| It is auto-generated with the purpose of maintaining the exact
| same semantics as the C code, with no regard to safety, best
| practices, etc.--of course it is messier than actual,
| handwritten Rust.
|
| As c2rust says in its documentation [1], it's meant to be the
| first step in an otherwise manual and incremental port of a
| codebase from C to Rust, and the author recognizes this in
| their closing remarks:
|
| > The next goal is to convert the codebase to safe Rust.
|
| [1] https://github.com/immunant/c2rust/raw/master/docs/c2rust-
| ov...
| johnisgood wrote:
| What a wonderful image... and it ends there.
| _danielle_ wrote:
| I mean what else would you expect when C is ported directly to
| Rust? Rust programs typically aren't written anything like C
| programs are.
| johnisgood wrote:
| No shit sherlock.
| _danielle_ wrote:
| Then why make the original comment? :')
| Jaxan wrote:
| You should read one paragraph further. They did use c2rust but
| found it really bad and threw that out of the window. Then did
| it manually. So in the end it is _not c2rust_.
| johnisgood wrote:
| Yeah, looking forward to it.
|
| Have you read the conclusion, by the way?
|
| It is probably going to end up being vaporware.
| gmoque wrote:
| I love the attitude on this project and most of the comments are
| supportive. While rewriting a mature application to another
| language always sounds like a bad idea, there are so many
| learnings along the way. It's not about the end it's about the
| process.
|
| Given the traction you got here and the advancements in AI, I'm
| sure this can become a very attractive hobby project for Rust
| beginners, there's probably a lot of easy bugs to fix. Fixing
| bugs, adding new features, and optimizing the code is all you
| need.
|
| Here's an idea to get the ball rolling: Create a scratch buffer
| for Gemini CLI (or your favorite LLM) and enable it to interact
| with the various windows and panes of the tmux session.
|
| Here's my use case, I use synchronized panes to send the commands
| into multiple servers, but some commands sometimes fail for
| various reasons. What if I can just ask the AI to send a series
| of commands and react based on the output and adjust along the
| way. It's like a dynamically generated custom shell script on the
| fly.
| a-dub wrote:
| the one thing i wish tmux supported was remote connections to
| several backend instances.
| Carrok wrote:
| Use tmuxinator to start multiple ssh/mosh connections.
| malithmcr wrote:
| Rust is king
| aldousd666 wrote:
| Great way to learn a new language!
| cchance wrote:
| Next step slowly porting unsafe code to safe rust? lol
| FullyFunctional wrote:
| why is that funny? I've done exactly this (in a processional
| setting): c2rust to get something functional and then
| incrementally rewrote the code while producing unit tests
| (approval tests via insta are particularly handy). The end
| result was a codebase which was much easier to maintain, with
| much better tooling and tests.
| bakugo wrote:
| https://github.com/richardscollin/tmux-rs/issues/9
|
| 120 comments and nobody has mentioned the use-after-free
| triggered by closing a window. Rust truly is the safest language.
| philosophty wrote:
| _" Despite the generated code working, it was basically
| unmaintainable and 3x larger than the original C."_
|
| Which makes C2Rust seem pretty useless?
|
| _" I've recently reached a big milestone: the code base is now
| 100% (unsafe) Rust. I'd like to share the process of porting the
| original codebase from ~67,000 lines of C code to ~81,000 lines
| of Rust (excluding comments and empty lines)."_
|
| And yet somehow a hand-ported (and still unsafe) rewrite of a C
| program in Rust is still almost 20% larger?
|
| If I recall, the Go gc compiler was _automatically_ converted
| from 80K lines of C to 80K lines of Go. A hand-ported version
| would have been much smaller.
| kevincox wrote:
| > Which makes C2Rust seem pretty useless?
|
| It does what took him 6 months in seconds. Of course it isn't
| perfect, failing to keep the name of constants being an obvious
| flaw. But presumably with a few improvements you could then
| spend some of that 6 months cleaning up the code and still save
| time. Sounds like C2Rust is almost there, but not quite yet.
|
| > And yet somehow a hand-ported (and still unsafe) rewrite of a
| C program in Rust is still almost 20% larger?
|
| Size is not a very useful metric. But the port is still half-
| done. He has got it working in Rust, so now he is ready to do
| the "hard" part of the port and actually rewrite the "basically
| C" code into idiomatic Rust. That is where you expect to get
| safety improvements and hopefully more readable code.
| philosophty wrote:
| _" It does what took him 6 months in seconds."_
|
| It generated unusuable garbage code in seconds, which is
| nothing like what he wrote by hand in six months.
|
| _" Size is not a very useful metric."_
|
| Size is a very useful metric. Counting tokens is more
| accurate estimate of "size" but lines of code is a good first
| approximation.
|
| The entire purpose of high level languages is to make it
| possible to do more with less code. Size isn't all that
| matters but it's very important.
|
| Rust code is not only more verbose than C it's also much more
| irregular and complex. That 20% increase in lines of code is
| probably more like 50% increase in code complexity, and this
| is without safety.
|
| Just compare tokens in the post's example: //
| cmd-kill-session.c RB_FOREACH(wl, winlinks,
| &s->windows) { wl->window->flags &=
| ~WINDOW_ALERTFLAGS; wl->flags &= ~WINLINK_ALERTFLAGS;
| } // cmd_kill_session.rs for wl in
| rb_foreach(&raw mut (*s).windows).map(NonNull::as_ptr)
| { (*(*wl).window).flags &= !WINDOW_ALERTFLAGS;
| (*wl).flags &= !WINLINK_ALERTFLAGS; }
| sanity wrote:
| How do people feel about tmux vs zellij?
| imbnwa wrote:
| Zellij has interesting ideas, but it has a ways to go. You can
| arbitrarily rebind the base modes and their actions, but you're
| F'd if those conflict with a plugin's, which seem to all have
| hardcoded key binds.
| seyz wrote:
| > I don't really have a good reason. It's a hobby project. Like
| gardening, but with more segfaults.
|
| Love it. You definitively deserve your +350 points!
| Jtsummers wrote:
| It's not my project, I saw that line and read the rest and
| thought it was interesting so I submitted it.
| alberth wrote:
| Slightly OT: it didn't dawn on me until recently that terminal
| multiplier (like tmux) is a terminal itself.
|
| And as a result, you could be running the greatest / fastest /
| most feature rich _desktop_ terminal ... but if your multiplier
| doesn't support something - it hinders your fancy desktop
| terminal.
|
| Short 3 min video explained by Ghostty creator
|
| https://youtu.be/o-qtso47ECk
| blibble wrote:
| what is it with these re-implementations by different authors
| pinching the name of the original project?
|
| you want to re-implement a well known project, fine
|
| call it something else
| hnlmorg wrote:
| That ship sailed right at the birth of open source. Just look
| at the number of different reimplementations of coreutils.
| encom wrote:
| No I like the idea of appending "-rs", because it makes it much
| easier to filter out.
| bitbeq wrote:
| wfd
| dangoodmanUT wrote:
| I love this, but the examples they show of their snippets are
| really, really not rust idiomatic.
|
| Like they've basically thrown away all the rust patterns and just
| wrote a c program in rust (eg all the raw pointers)
| pizlonator wrote:
| I just ported tmux to Fil-C in less than an hour (that included
| porting libevent and gettings its test suite to pass).
|
| Works great and it's totally memory safe
___________________________________________________________________
(page generated 2025-07-03 23:00 UTC)