←back to thread

Introducing tmux-rs

(richardscollin.github.io)
857 points Jtsummers | 4 comments | 03 Jul 25 15:03 UTC | HN request time: 0s | source
Show context
uecker ◴[03 Jul 25 15:55 UTC] No.44456333[source]▶
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....

replies(4): >>44456413 #>>44456755 #>>44459370 #>>44459965 #
antonvs ◴[03 Jul 25 16:32 UTC] No.44456755[source]▶
> But otherwise, maybe better not rewrite working code....

Except that the eventual result allows for extension and improvements in a memory-safe language.

replies(2): >>44456866 #>>44458838 #
uecker ◴[03 Jul 25 16:41 UTC] No.44456866[source]▶
There seems to be some rather irrational obsession about this.
replies(2): >>44456899 #>>44457353 #
antonvs ◴[03 Jul 25 16:43 UTC] No.44456899[source]▶
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.

replies(4): >>44456943 #>>44457046 #>>44459920 #>>44460258 #
chillingeffect ◴[03 Jul 25 16:57 UTC] No.44457046[source]▶
> 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.

replies(1): >>44457154 #
antonvs ◴[03 Jul 25 17:10 UTC] No.44457154[source]▶
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.

replies(2): >>44457529 #>>44457555 #
Spivak ◴[03 Jul 25 17:49 UTC] No.44457529[source]▶
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).
replies(4): >>44457638 #>>44458278 #>>44458741 #>>44458771 #
1. antonvs ◴[03 Jul 25 20:13 UTC] No.44458771{3}[source]▶
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.

replies(1): >>44459315 #
2. uecker ◴[03 Jul 25 21:23 UTC] No.44459315[source]▶
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.
replies(1): >>44459982 #
3. antonvs ◴[03 Jul 25 23:31 UTC] No.44459982[source]▶
> There are certainly a lot of dangerous aspects, but most are rather easily avoided.

This is an almost childish claim. If they're so easily avoided, how do you explain the enormously long list of CVEs for C and C++ programs?

> I do not think C++, Zig, or Go have a fundamental advantage.

We agree on that. They objectively do not. They're all an attempt to continue the C legacy. Go specifically is particularly ridiculous, having been designed quite recently by people from the 1970s who steadfastly refused to learn any lessons from the last 50 years of programming language development.

To be clear: I'm from the 1970s as well. I learned FORTRAN in 1977. But unlike the designers of Go, I didn't allow my understanding of programming language design to stagnate in the 1970s. I learned things. I studied things. I discovered things.

Do you believe that C is the ultimate in system programming language design? If you agree that it's not, then what are we arguing about exactly?

replies(1): >>44464586 #
4. donkeybeer ◴[04 Jul 25 13:53 UTC] No.44464586{3}[source]▶
How many users and eyes do these "low CVE" Rust, Go whatever projects have?

While I'd hardly disagree C and even C++ is lacking in memory safety compared to some newer languages, you are forgetting to normalize for sheer scale and userbase. If you have a Go project with the scale of popularity of Linux or Chrome or so on, then we can compare bug counts directly.