Even when I need what C does "well" from the author's pov I can just wrap my code in a big unsafe {} in Rust.

I still get a bunch of things from the language that are not safety- but ergonomics-related and that I would't want to miss anymore.

Rust is much more than safe(r) C, it is different approach of architecting apps to have safer relations between components. Now that I am looking at my old code, I see how it would benefit from this paradigm.

And it also a 'problem' with Rust - it requires one to think differently. You can write Rusty code in C, and indeed results are just better, but trying to write Rust in C style would lead to fighting compiler and suffering.

Other languages, like Zig or Go, they chose different approach - to decorate C with modern features, and that works too.

It cannot be matched in in C, even with a lot of macro magic. Plus, C is way too lax with type strictness and enums.

>Sometimes you don't want a language that keeps you safe. Sometimes you want one that simply gets out of your way.

D lang is a wonderful Goldilocks in this regard between C and Rust. It has D-as-better-C [1]. There's no head scratching macro, excellent meta programming, bare metal programming and fast compile time and run time [2]. The programming syntax is very intuitive with UFCS [3].

[1] Better C:

https://dlang.org/spec/betterc.html

[2] Ask HN: Why do you use Rust, when D is available? (255 comments):

https://news.ycombinator.com/item?id=23494490

[3] Function:

https://dlang.org/spec/function.html

The concepts are probably the authors, but the text we are seeing is probably the LLMs.

Regardless of the LLM overtones, this is still decent content.

<rant> Rust gives you: Memory safety (mostly), No use-after-free, double-free, buffer overruns in safe Rust.

It does not give you: logic/protocol/cryptographic correctness, supply-chain integrity, side-channel resistance, malicious dependency immunity, auditability, reduced attack surface, or reduced complexity.

In other words, Rust solves one class of bugs extremely well. It solves none of the hard ones.

I get it, memory corruption bugs are Loud, measurable, easy to point at, and easy to sell to management.

That's why they dominate the narrative.

My biggest issue/concern is the dependency explosion problem.

Classic C Example: - ~N lines of code - A small number of carefully curated libraries - Mostly static linking - Painful to write - Painful to maintain - Possible to audit

Rust rewrite: - Core project + - 50 direct dependencies + - 300 transitive deps + - 900 crates total + - Thousands of maintainers you have never met + - GitHub accounts that may disappear tomorrow + - Build scripts executing arbitrary code at compile time

Security claim: "Memory safe!" Reality: Attack surface inflation by 1–2 orders of magnitude

You've traded: "I might screw up a pointer"

for: "I trust a thousand strangers, their CI pipelines, their update hygiene, their threat models, and their long-term incentives."

...

Rust’s memory-safety guarantees are genuinely valuable, especially for new development. Where I become skeptical is when a rewrite significantly expands the dependency graph. At that point, the security model shifts from "local reasoning enforced by the compiler" to "transitive trust in a very large supply chain". That trade-off isn't always acknowledged, and in some contexts, especially high-assurance systems, it deserves more scrutiny.

</rant>

The only reason to pick Rust instead of one of those, is exactly because the memory safety without GC that it offers, when any form of automatic resource management, be it in whatever form, is not possible, or welcomed by the domain experts.