The Rust for Linux project

In C, I would argue many things are presented as 'overly simplified' with hidden behaviors that many developers may not consider until it bites you with undefined behavior. The typing system is not very strict which gives many footguns, there's practically no such thing as memory safety, etc. I think you know all this, and you're right that Rust adds features to be safe, and programming under Rust with this subset takes some time to think about how you want a program to function.

What I'm getting at is that it takes time and experience with Rust to be able to formulate an effective and friendly program structure, just like many other programming languages. You wouldn't be expected to pick up Haskell and know exactly the 'right' way to make a web server application, and Rust is no different. There's also never one obvious way to construct a program; sometimes you do need to scrap your current code and start over, regardless of the language used, and that happens less as you learn about the tools you are using.

The additional features of Rust do add more to consider in your design and may add to technical debt later on, but with experience, you gain insight into how your program synergizes with the Rust model and it becomes less of a burden. Likewise, the clearly marked unsafe portions of code, enforced typing model, and lack of undefined behavior remove a lot of time reviewing code and running static checkers against your program, of which C++ does not really remove despite being more 'feature-rich' than C and containing things like templates that Rust doesn't have.

Seems to me your concern applies mainly to green-field development in Rust. Actual *maintenance* presents these questions less often, and when it does the solutions will be constrained by the patterns already set up.

But it would be interesting to collect more specific examples and see what can be done to provide guidance. I personally don't feel this burden myself. Maybe it's because I've been writing Rust code for five years, but even when I look at the code I wrote in the first year I think the design generally holds up.

I understand the fear, but it doesn't match my experience.

First the most obvious: paying technical debt (aka refactoring) is easier in Rust, because an API change will be noticed by the compiler in all callers, whereas in C many would be wrongly ignored. I rarely get the "needs a refactor but I'm too afraid to break things so I'll leave it" feeling with Rust.

Second, Rust helps making APIs that are harder to misuse, actively fighting technical debt. That's what you encountered when you realized you needed to throw away your first version(s). You probably should throw away your first C version too, but the compiler and base APIs don't tell you that. In a way, rustc is your first reviewer, making the human reviewer's job simpler. It might cause some anger when you're still learning that API or Rust itself, but it seems worth it.

Define "worse", on which axis?

Debugging undefined behaviors and race conditions or refactoring existing code? I have my preference...