Introducing tmux-rs

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.

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.

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.

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

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

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.

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

What's wrong with FORTRAN?

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.

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.

C23 is very different than C89. C89 variable declarations are decidedly not fun.

Embed, designated initialization, and constexpr are really nice adds.

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/

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.

Lol, if you believe such surveys.

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)

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.

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.

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.

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?

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.

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

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.

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.

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.

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

I don't follow; tmux-resurrect isn't written in C and is mostly useful to keep sessions across reboots.

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

FORTRAN means what it's always meant. The standard is a guide for the implementor. The user needs to code to the implementation.

It's a different way of thinking about languages than most people usually do, but it's been true for FORTRAN since the 1950s and is true to some extent of every language with multiple implementations today.

Wow, that's the most condescending opening to a comment I've seen in a while.

What adoption? Blog posts? Echo chambers? Rust peaked. The hype pushers don't want to believe it but that is the reality. Absolutely zero shade to Rust.

You support my point while also missing it.

No, I'm disagreeing with you that it's getting worse, as well as that it's all that bad in the first place.

No, that is likely not true. There are platforms today for which C-based tmux runs but Rust never will. It's not that we are simply waiting for the backport of Rust to magically appear for them, it's quite a certainty that it will basically never appear.

> It's not that we are simply waiting for the backport of Rust to magically appear for them, it's quite a certainty that it will basically never appear.

Abstraction happens on the level where tmux requirement is irrelevant. When the usage of Rust gets wider, people start adding support on compiler level for other needs. It is inevitable.

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

And what makes you think today's "principled designs" won't get the boot a few years down the line too? These things are cyclical and rarely based on any real mathematical reasoning.

It's also not about sticking to what I already know for me. I don't currently know FORTRAN but wish to learn FORTRAN.

There are more factors to language use than design pattern fads. Like efficiency for example, which almost any modern garbage collected or managed language cannot meet beyond a certain level. And that usually gets worse the more "powerful abstractions" one adds. I want to learn FORTRAN because I have been told it has real benefits in terms of ergonomics for efficient code, ie normal looking FORTRAN code is faster than normal looking C/C++/Rust.

Efficiency is a real, concrete and measurable quantity. It is not subject to the fad of the day.

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.

It is not suited to cases where the machine state is experienced by the user at all times (games, hardware-control, real-time transactions). It is very suited to cases where the machine is expected to act like a SSBN, disappearing from view until a large floating-point calculation is ready.