[linkage]

> I cannot see why in the face of astounding evidence like this, you would completely dismiss it.

Because it's not a silver bullet. That safety comes at a cost; Rust is much more difficult to learn than C or Zig and the compilation time for code with equivalent semantics is an order of magnitude greater. It has also added a great deal of toolchain complexity to projects like the Linux kernel.

People have decided that the pros outweigh the cons in those particular cases, but those cons exist nonetheless.

[dgacmu]

Rust is more difficult to learn the basics of than C, but I'm not sure it's more difficult to learn to write memory-safe code in Rust than in C. It's also not clear to me it's that much harder to learn Rust than it is to learn how to write equivalently-high-level code in C++ _unless you end up in one of the areas where Rust is really hard_. But a lot of systems code doesn't end up in those areas. Some does, and then you have to go fishing for a crate that does things for you. C++ just has a lot of corners you can get sucked into, and the legacy mix of multiple generations of C++ coding styles / OO stuff makes for some really tangled messes out there.

(fwiw, I teach undergrad systems programming in C, I use Python at the startup, and I use a mix of C/C++/Rust in research.)

I would personally much prefer to use Rust for code exposed to external untrusted input than to use C. I have substantially more confidence that I would not add exploitable bugs given the same time budget.

[josephg]

My favorite framing for this is that rust front loads all the pain.

C and C++ are incredibly subtle languages. But you can get a lot of code written before you run into certain foot guns in C and C++. This gives those language a more enjoyable on-ramp for beginners.

In comparison, rust is a wall. The compiler just won’t compile your code at all if you do anything wrong. This makes the act of learning rust much more painful. But once you’ve learned rust, it’s a much smoother experience. There’s far fewer ways for your programs to surprise you at runtime.

[arw0n]

At least the Rust compiler gives pretty good advice on what is going wrong. And for complete beginners, agentic AI can soften the pain a lot if used correctly. By used correctly I mean the following work flow:

1) Design in correspondence with AI. Let it criticise your ideas, give you suggestions on tools/libraries/techniques, and have concepts and syntax explained to you. Stay aware that these models are sycophantic yes-machines.

2) Implement yourself.

3) Debug in collaboration with AI. If you ask a question like "I'm getting [error], what are the most likely reasons for this happening?", you can save a lot of time finding the issue. Just make sure to also research why it is happening and how to solve it independently.

4) Let AI criticise your final result and let it offer suggestions on what to improve. Judge these critically yourself.

There is some worth in spending hours trying to fix a bug you don't understand, it builds resilience, helps you get familiar with a lot of language topics, and you probably won't make the same mistake again. But the above approach is a pretty good compromise of letting AI help where it excels, while still keeping enough control to actually learn something yourself.

I believe that Rust is the language benefiting the most from agentic AI, because the compiler is such a strong gate-keeper, and the documentation of almost all aspects of the language is comprehensive and clear. The biggest pain points of Rust are also reduced by AI: Front-loaded learning curve is softened, refactoring is something gen AI is actually decent at, and long compile times can be spent productively by already planning out the next steps.

[josephg]

> I believe that Rust is the language benefiting the most from agentic AI

Except in my experience, chatgpt and claude both struggle to write rust code that compiles correctly. Chatgpt is pretty good at complex tasks in typescript like "Write a simple snake game using (web framework x). It should have features X and Y". Its can be surprisingly good at some complex problems like that.

If you try the same in rust, it often fails. I've also had plenty of situations where I've had some complex borrowing error in rust code, and chatgpt just can't figure it out. It goes in loops. "Oh I see the problem. Sure, this should fix it ..." except the "fixed code" fails in just the same way.

I'm not sure why. Maybe there's just not enough rust code in the training set for chatgpt to figure it out. But rust is definitely a weakness of the current generation of models.

[blub]

The pain will always remain when refactoring or changing code, with modifications cascading in the function and type definitions.

If a language is hard to write at first, it’s always hard to write. The saving grace of C++ is that one mustn’t use the overcomplicated functional aspects, template meta-programming, etc. Through some amazing circumstances, all of the above (or their equivalents) + async is exactly what idiomatic Rust code has become.

Inside Rust there is a not so ugly language that is struggling to come to light and it is being blocked at every step.

[josephg]

> If a language is hard to write at first, it’s always hard to write.

That seems obviously false. Most fancy programming languages are difficult to write at first, C++ included. But they all get easier over time.

Rust got way easier to write over time for me. I'm soooo much more productive in it now compared to when I started. Does C++ not get easier to write over time too?

[blub]

You’re mixing up developers becoming more competent with the language becoming easier.

Neither C++ nor Rust are becoming easier unless new features are added which make them simpler to use in some circumstance.

C++11 & co did make many things simpler. For Rust I don’t know the details of what’s upcoming; it doesn’t seem to be getting simpler.

[steveklabnik]

A significant amount of Rust’s “new” features over the last years have been “yeah if you tried to use x and y together, that didn’t work, but now it does.” From an end user perspective, a lot has been made more straightforward over time.

[mx7zysuj4xew]

How about you teach some of those students to Bootstrap a Linux cross compile both with and without rust then come back and answer this reply again

[dgacmu]

This seems unrelated to the topic at hand, which is whether Rust results in a net improvement in the time required to deliver (systems) software that meets a particular set of requirements and those requirements include resilience to handling untrusted inputs.

Of course adding an additional set of tooling complicates an environment. I'm sure that was the case for Google in adding Rust to Android as well. And yet - it seems to have proved worth it. And I suspect that in the long term it will prove likewise for Linux, because Linux shares the same requirements and has a similar threat model it needs to guard against.

[mx7zysuj4xew]

The reason it is relevant is this:

"This seems unrelated to the topic at hand, which is whether Rust results in a net improvement in the time required to deliver (systems) software"

A lot of your argument assumes that you've already have an entire working build environment readily available. If this is not the case, what used to be a fairly straightforward C compile now becomes an massive ordeal

[spockz]

Is it harder to learn than C? For sure it is a bit harder to get started. But is it also harder to learn than writing proper C(++?) with the same amount of quality in terms of lack of bugs ?

[linkage]

C has plenty of high quality linters like ClangTidy that can teach junior and intermediate developers what not to do. Granted, even with linters, C projects typically have more vulnerabilities than Rust projects, but C has fewer concepts a developer must know to produce working code. For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics. In C, you just need to know what a struct is and what a pointer is.

[jancsika]

> In C, you just need to know what a struct is and what a pointer is.

Suppose we have a team of experts busily analyzing every single state of the code. They are reading/valgrinding/fuzzing/etc.-- in real time as the intermediate developer writes code.

Each time the developer tries to compile, the team quickly votes either to a) remain silent and leave the dev alone, or b) stop compilation because someone thinks they've discovered an invalid read/write or some other big no-no that the compiler will not catch (but the Rust compiler would catch).

If they choose b, the experts stop for a bit and discuss the clearest way to communicate the hidden bug. Then they have a quick conversation with the intermediate developer. Suggestions are made, and the whole process repeats.

Is this process substantially faster than just learning Rust?

Edit: clarification

[baq]

> to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics. In C, you just need to know what a struct is and what a pointer is.

It is misguided to say that recursive data structures should be easy to write. They are difficult to reason about and the Rust compiler is right to point this out. CS is not engineering, you should be writing those trees with a pencil on a piece of paper as Dijkstra intended, not in C.

[crote]

How often do you DIY a self-balancing binary tree? Sure I wrote a few in college, but in the real world you are almost always just using an existing library. Optimizing for edge cases like that doesn't make sense.

And is your hand-written C implementation going to be safe and correct. You didn't mention any kind of locking or atomic operation, so is it going to unexpectedly break in a multithreaded environment?

The concepts of Rust are definitely more complicated, but in practice it just means that C makes it easier to shoot yourself in the foot. It's easy, but is that really the most important thing here?

[nine_k]

This assumes a perfect student who is not going to make any mistakes while writing their code, not even a typo. If an error is introduced, things become much harder on the C side. The compiler may miss it. It could manifest as a bug that only occurs in certain non-obvious circumstances, and manifests erratically (e.g. an out-of-bounds write clobbering data of a node next to it in the heap). Rust would most likely just not allow such a bug to be introduced.

In the same vein, driving on a modern busy road requires you to know about lanes, speed limits, various signs, traffic lights, rules of turning and merging, etc, etc. A road without all of that, where a steering wheel plus two pedals suffice, of course still allows you to drive, and drive fast, but it requires much more attention from a driver; many driver's mistakes are noticed later, and lead to more dangerous accidents.

[SkiFire13]

> For example, to implement a self-balancing binary tree in Rust, you need to first understand reference counting, `RefCell`, and ownership semantics.

This assumes a self-balancing binary tree must have nodes with parent pointers. Without those you don't need reference counting and without that you don't need `RefCell` either.

[woodruffw]

How often do you find yourself implementing self-balancing trees in either C or Rust?

[tcfhgj]

once in university

[kibwen]

> Because it's not a silver bullet.

It does look like a silver bullet, actually. In the context of software engineering, "silver bullet" inevitably leads to Fred Brooks:

'"No Silver Bullet—Essence and Accident in Software Engineering" is a widely discussed paper on software engineering written by Turing Award winner Fred Brooks in 1986. Brooks argues that "there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity."

Reducing memory-safety vulnerabilities by 5000x compared to the prior approach is not just a silver bullet, it's an arsenal of silver bullets.

> the compilation time for code with equivalent semantics is an order of magnitude greater

The time it takes to write and run the comprehensive tests for C and Zig code to demonstrate anything even approximately in the ballpark of what Rust gives you for free is a multiple orders of magnitude greater than whatever time you spent waiting for the Rust compiler. Why care about the time it takes to compile trivially incorrect code, rather than caring about the total time it takes to produce reliable software, which is demonstrably lower for memory-safe languages like Rust?*

[mcherm]

To me, those sound like meaningful pros and cons, not a reason to completely dismiss it.