I think this is weirdly resonated with me. I used moved to Rust from C for embedded programming, and realized that my whole paradigm shifted on how I write programs.
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.
Forget safety. Using enums in Rust is sheer delight. The fact they can even contain associated data is the really powerful. That alone makes me love the language. Especially with bitfields.
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.
Rust has two parents; it got its looks from C, but much of its character was inherited from its other, less commonly mentioned parent -- ML. Rust has a variation of the Hindley-Milner type system, quite similar to ML (or Haskell). Rust's enum and struct are algebraic data types, also known as sum or product records or types. The type system and pattern matching enable declarative and functional styles of programming that are much less natural to express in C.
That’s right. And forget about the existing rustc compiler implement. If you have something in Rust like
let a: HashMap = immutable_map.iter().map(…);
then you can infer from the semantics that the ordering doesn’t matter and whether it can be parallelized. C doesn’t have the ability to express what you want to happen, just how to do it. That gives Rust far more opportunity for optimization than C possibly can have.
OTOH, it wasn't until recently that you were able to write something like `std::array<T, N>` in rust. Even now, there are restrictions on the kinds of expressions that N can be.
>None of this means Rust is "bad" or that C is "better". It means they optimise for different values. Rust optimises for correctness and maintainability under heavy abstraction. C optimises for transparency and minimalism under extreme constraints.
>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].
Uniform Function Call Syntax seems neat, but is it really uniform? In other words, can you call a random method defined on a class via method(class, parameters)? Or are some things more uniform than others?
The problem is not that {language} does or does not do or have {thing}. The problem is managers expecting the work product of coders who only half know the language that they are working in to be productionizable.
This looks like it was written by an LLM. Not complaining, because my major use of LLMs is rubber-ducking, not code-generation, and I very often get responses like this when doing repeated iterations and deep-diving into a review/comparison.
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.
You are correct. The final output was polished by ChatGPT, but I originally presented the basic ideas in a few paragraphs. The LLM added a sense of flow and persuasiveness which are somehow lacking in my rather dry and non-native English writing style.
Too many people, myself included, often skip LLM content.
After I am done rubberducking with the LLM I write my own code. I can you should do that too. Leave a few days after your session to let the discussion percolate in your mind, then write the post and only then check the discussion again to see if any details can be added.
In all fairness, I dont actually write blog posts like this, I just bang 'em out whenever I feel like, so not sure of it will work as well as I think it would.
Okay, I like Rust, really... But, I totally agree it's not just about memory safety.
<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.
Yet another Rust article that ignores the choice among memory safe languages, including the ML linage that inspired Rust's type system.
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.
As someone who has written C and C++ for 35 years and Rust for a decade now, the last five years professionally, I don't see the point.
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.
I think this is weirdly resonated with me. I used moved to Rust from C for embedded programming, and realized that my whole paradigm shifted on how I write programs.
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.
"A language that doesn't affect the way you think about programming is not worth knowing." ― Alan J. Perlis
Learning Rust definitely made me a better C programmer.
Forget safety. Using enums in Rust is sheer delight. The fact they can even contain associated data is the really powerful. That alone makes me love the language. Especially with bitfields.
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.
Rust has two parents; it got its looks from C, but much of its character was inherited from its other, less commonly mentioned parent -- ML. Rust has a variation of the Hindley-Milner type system, quite similar to ML (or Haskell). Rust's enum and struct are algebraic data types, also known as sum or product records or types. The type system and pattern matching enable declarative and functional styles of programming that are much less natural to express in C.
That’s right. And forget about the existing rustc compiler implement. If you have something in Rust like
then you can infer from the semantics that the ordering doesn’t matter and whether it can be parallelized. C doesn’t have the ability to express what you want to happen, just how to do it. That gives Rust far more opportunity for optimization than C possibly can have.C != C-derived languages
In C++ this was possible already in C++03.
OTOH, it wasn't until recently that you were able to write something like `std::array<T, N>` in rust. Even now, there are restrictions on the kinds of expressions that N can be.
Just pointing out that this cuts both ways.
>None of this means Rust is "bad" or that C is "better". It means they optimise for different values. Rust optimises for correctness and maintainability under heavy abstraction. C optimises for transparency and minimalism under extreme constraints.
>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
I feel like D was gaining momentum and then stopped, and I’m unsure why.
I’ve read about competing RTLs etc but none of that really seems a blocker. Rust has changed an awful lot too since it’s early days.
> UFCS
Uniform Function Call Syntax seems neat, but is it really uniform? In other words, can you call a random method defined on a class via method(class, parameters)? Or are some things more uniform than others?
The problem is not that {language} does or does not do or have {thing}. The problem is managers expecting the work product of coders who only half know the language that they are working in to be productionizable.
This looks like it was written by an LLM. Not complaining, because my major use of LLMs is rubber-ducking, not code-generation, and I very often get responses like this when doing repeated iterations and deep-diving into a review/comparison.
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.
You are correct. The final output was polished by ChatGPT, but I originally presented the basic ideas in a few paragraphs. The LLM added a sense of flow and persuasiveness which are somehow lacking in my rather dry and non-native English writing style.
I feel you should avoid this.
Too many people, myself included, often skip LLM content.
After I am done rubberducking with the LLM I write my own code. I can you should do that too. Leave a few days after your session to let the discussion percolate in your mind, then write the post and only then check the discussion again to see if any details can be added.
In all fairness, I dont actually write blog posts like this, I just bang 'em out whenever I feel like, so not sure of it will work as well as I think it would.
Okay, I like Rust, really... But, I totally agree it's not just about memory safety.
<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>
Yet another Rust article that ignores the choice among memory safe languages, including the ML linage that inspired Rust's type system.
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.
Article is about C. So non-GC memory safe language, as first, choice makes sense here.
Not really, there are tons of software written in C that should have never came close to a C compiler in first place.
Even the UNIX and C authors agree with this, given what they worked on, in OS design and programming languages post C.
Something that many glance over, what have their UNIX idols actually done after UNIX System V.
Thus the first question already is that kernel code or not, and if not, why should it be written in C versus any other safer alternative.
Actual reasons like performance numbers required by the application, or existing SDK availability, not the "because I like it".