Rust happens to be an extremely good tool. There are definitely situations where it absolutely sucks. e.g. Zed is a heroic effort, but look at the code and you'll see that we still haven't figured out how to do Rust UIs.
We may disagree on the premise that humans are generally incapable of correct and safe manual memory management, but that's a degree of distrust I hold for myself. You may have never written a memory bug in your life, but I have, and that renders me completely incompetent.
If a project in an unsafe language has ever had a memory bug (I'm looking at you, Bun), the maintainers objectively have a track record of not being capable of manual memory management. You wouldn't put a person who has a track record of crashing busses at the wheel of a school bus.
And Rust isn't the only memory-safe language. You can turn to Java, Go, C#, Type/JavaScript, and whole bunch of others. Rust just so happens to have ocaml tendencies and other things that make it a joy to read and write, so that's definitely preference on my part. One of these days I'll learn ocaml and possibly drop Rust :)
> You may have never written a memory bug in your life, but I have, and that renders me completely incompetent.
This feels overly binary. Memory management bugs is just one class of bugs, and there have been many other bugs leading to security issues or defects.
If you apply the standard "has ever written a bug" → "completely incompetent" you will have to stop using software, and if you think about it most other technology too
Memory safety is a very useful trait for a language though, and as you say provided by a whole bunch of different languages nowadays
> It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next.
This is also why memory safety is table-stakes when it comes to formal verification of the underlying program logic. You can't solve logic bugs (even where that's known to be feasible, such as for tightly self-contained, library-like features) without solving memory safety first.
Do note that with modern compilers it's surprisingly hard to accidentally do something that is always guaranteed to write to 0. Because it is UB, and an optimizing compiler is allowed assume that it doesn't happen. This can lead to seemingly crazy things like a variable that is set to zero, and when you deref through it it gives you something completely different instead. Because if a variable is first set to zero in all code paths, and then complex logic usually sets it to something else, after which it is dereferenced, the compiler is allowed to notice that the path where it is accessed without being first set to something else never happens, and then it is allowed to notice that the first write to the variable is dead because it's never read before being set to something else, and thus can be eliminated.
Is there a difference between c++ and java/go/etc if you enforce at code review for C++ to use only auto memory management like smart ptrs, containers, etc? I guess the only difference would be c++ can have diamond problem that's solved in a specific way, but that's relatively easy to spot with compilers, but otherwise...
Imo the strong point of rust is compile error if you try to use an obj after move (unlike c++ with undef behavior and I guess it should be the same for java/c#), or that you can't modify a container if you hold a ref/pointer to some of it's elements/range which may cause invalidation in C++ case due to realloc
Yes, because code review isn't common, it is at the same level as writing documentation, or unit tests in most companies.
Unless there is some DevOps freedom to at least put something like Sonar or clang tidy on the build pipeline breaking PR that don't play by the rules, and even then you cannot prevent everything via static analysis rules.
I think it's (mostly) sufficient to have a regex on git change-set for "new" "malloc" "calloc" keywords to cut most of such stuff if you have such a policy.
Documentation / UT are harder to define (what is good documentation, is UT covering everything?), but usage of manual memory handling can be spotted relatively easy automatically. There can be some exceptions for 3rd party libs interaction if it's absolutely necessary but detecting such occurrences and keeping track of them is relatively easy.
See, already there you missed all the C language constructs that C++ is copy-paste compatible with, and should only be used inside unsafe code blocks.
Which in C++ good practices means type safe abstractions not exposing any kind of C style strings, arrays, casts, pointer arithmetic,....
Unfortunely still relatively rare, some of us when we were the C++ Striking Force in the 1990's Usenet flamewars already advocated for such practices, most of them already possible with C++ARM, no need for modern, post-modern, rococo, baroque or whatever C++ style is going on with C++26 now.
I've been experimenting (thanks to Claude Code because it removes the headache drastically for me of Rust nuances, I'm not a Rust expert by any means) with Qt and Rust.
I discovered cxx-qt which is maintained by some Qt maintainers, which are all employed at KDAB. I had no idea KDAB or this project existed. It's been very smooth so far.
I can honestly say the barrier to building a GUI is very low with Claude, must to the dismay of others, but it beats me building an Electron app.
Zig would be an interesting contender back in the 1990's between Object Pascal and Modula-2, nowadays we know better.
For me while Go is definitly better than Oberon(-2), and Oberon-07, some of its design decisions are kind of meh, still I will advocate for it in certain contexts, see TinyGo and TamaGo efforts.
As old ML fanboy, you can find such tendencies on plenty of languages not only OCaml. :)
I see Rust as a great way to have made affine types more mainstream, however I rather see the mix of automatic resource management + strong type systmems as a better way forward.
Which is even being acknowledged by Rust's steering group, see Roadmap 2026 proposals.
> If a project in an unsafe language has ever had a memory bug (I'm looking at you, Bun), the maintainers objectively have a track record of not being capable of manual memory management
That's an interesting way to navigate the world. Do you hold this attitude towards other professionals? For example, if a lawyer ever lost a case by misinterpreting a law, they have a track record of not being capable to practice laws and should be disbarred?
There were (and most likely, still are) even memory bugs in Rust standard library[0]. By your logic the standard library maintainers objectively can't handle unsafe blocks.
Rust is just a tool. A decent tool that I think can be made better (by removing stuff and stop adding more stuff to the surface syntax). So I am down to criticize Rust.
However, I also don't understand how people don't see the usefulness of what Rust put to the mainstream: algebraic data types, sum types, traits, etc.
I also get super annoyed when people think Rust is only chosen for "safety". Says frustrating things like "so I can just use unsafe", because no you don't and if you do I would reject your changes immediately.
Honestly, in general, I am just annoyed when people don't use the right tool for the right job. And attempts to fix the tool with more bespoke stuff on top it.
> Says frustrating things like "so I can just use unsafe", because no you don't and if you do I would reject your changes immediately.
This is the kind of hostility (which is frankly toxic) that’s become associated with parts of the Rust community, and has fairly or not, driven away many talented people over time.
1000x yes. Rust is not a One True Language, there exists no One True Language. Rust made some improvements over previous languages (many of which were ported over from previous languages that demonstrated the value but weren't break out successes) and serendipitously those improvements added up to something that was really significant and unlocked interesting and useful capabilities. I'm never going back to how my workflows were before I learned Rust (though I still write in other languages everyday).
But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.
C, Python, Java, are just a couple random languages that were/are similarly influential. (C is of course orders of magnitude more influential, the only language more influential is probably COBOL?)
> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.
That language may well be Rust itself, especially if they manage to figure out the "how to deprecate standard library features across language editions and allow reuse of their idiomatic syntax?" problem.
Totally true. Similarly I think a C revival is more likely than people might think because of Fil-C, improvements to the language standard, and maybe hardware improvements like CHERI. Eg, maybe there will be a new generation of Fil-C like compilers, maybe C will get a lot easier, and maybe that will cause C to displace Python as the preffered pedagogical "first language" (which would really be reprising it's role). Not because it's easier than Python but because it's easy enough and we start emphasizing low-level optimization more because AI is eating all of our compute. Stranger things have happened.
I can see some interest in Fil-C, but some will still be against it due to the overhead it imposes (1.5x-4x worse performance, less deterministic since there's a GC), as well as the program will simply crash on arbitrary memory reinterpretation, use-after-free, and reading uninitialized memory. This is certainly better than it continuing, but certainly not as good as it could be.
CHERI has different characteristics in that it will crash for buffer overflows, but crashing on use-after-free is opt-in, it can only detect double-frees sometimes, it does nothing about uninitialized memory access, etc. It also requires adopting new hardware, which may be a hard sell.
In all I've mentioned above, I haven't even touched thread safety or integer safety which these do nothing about.
So with that being said, do as you please, but understand that simply adopting these is a different level of safety (program will not be exploitable but will crash) compared to something like Rust (program is not exploitable and will not crash because these issues are mostly* compile-time errors).
* "Mostly" since I mentioned integer safety which will be a runtime crash like the C safeguards, you can use unsafe, etc.
Really what I'm getting at is that people are not done innovating on C ergonomics and safety and that there is potential there. Not that there is a new shivel-ready paradigm shift that has arrived to C. I'm only saying that that may happen and that it is more likely than most people credit.
Fil-C is actually not very low-level efficient, Golang probably has better efficiency (being built from the ground up for lightweight concurrent GC) and a hypothetical support within Rust for "pluggable" GC heaps might be even more clearly preferable.
> But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change
I agree, and I'm interested to see what it is in the age of LLMs or similar future tools. I suspect a future phase change might be towards disregarding how easy it is for humans to work with the code and instead focus on provability, testing, perhaps combined with token efficiency.
Maybe Lean combined with Rust shrunk down to something that is very compiler friendly. Imagine if you could specify what you need in high level language and instead of getting back "vibe code", you get back proven correct code, because that's the only kind of code that will successfully compile.
If your LLM can output 10-100x the LOC output, and it's equally good at all languages, and you're not bound to an existing language choice or ecosystem, why not choose Rust?
Rust code will be faster, safer, and easier to ameliorate bugs in.
Rust seems like the best language to serialize business logic to now that LLMs are so good at it.
If the LLM makes a mistake in Javascript or Python, you literally won't know until runtime. With Rust, you'll know immediately and have really good compiler recommendations for fixes.
I think Rust is the best LLM language. I am somewhat biased: I've written Rust code for ten years, and I'm having a blast with Claude Code writing it for me instead now. But I've also used so many other tools and languages - enough to say that Rust has some unique advantages here. And also that Claude does a fantastic job emitting Rust.
LLMs emitting Python feels like building with clay. LLMs emitting Rust feels like building well-engineered steel skyscrapers.
I'm also having a really good time having LLMs write code in Rust. In Typescript they tend to abuse `any` or just cast stuff around, bypassing the type system at every corner. In Rust they seem to take compiler errors to heart and things tend to work well.
You might also have success asking your agent to run `eslint` at the end of every subtask and instruct it to always address lint errors, even if they are preexisting. I agree with your diagnosis; there's "implicit prompting" in Rust being more strongly typed and the agent "knowing" that going in but we can compensate with explicit prompting. (You do also have to tell it to actually fix the lints, I find, or it will conclude they aren't relevant.)
I'm curious about the exact exchange that prompted the author to say this.
> refuse to admit there are alternatives to RAII
I'm even more curious about this. Can the author or anybody else explain what this means specifically? Can anybody list those alternatives other than GC and RC?
PS: Computer Science isn't exactly my primary professional competence.
I agree with this (short and sweet) piece. I'm Rust user but the crab-hype turned me off for the long time.
Personally I'd prefer writing Haskell but there are sharp edges I can't overlook (like constantly breaking LSP of 11/10 difficulty on producing distributable binaries).
I cringe every time I spit out 50 lines of boilerplate just to get C done Rust, but it's best tool I found that's good enough in many scopes.
Overly enthusiastic Rust evangelists can be annoying, but nowhere as much as C++ or C advocates defensively claiming memory safety isn't a big deal, and they are going to have it in the next version of the language anyway.
I find my experience with Erlang has helped with the (considerable) learning curve for Rust, but I still prefer Go for most use-cases.
Not even C/C++, only if vim and emacs are the only experience one has ever had.
See Visual C++ (with hot code reloading, incremental linking, AI integration, on the fly analysis), QtCreator, Clion (comparable with VS in many options), C++ Builder (with its RAD capabilities),....
Cargo is great as long as it is only Rust code and there is little need to interop with platform SDKs, then it is build.rs fun.
Rust is boaring! I ll never use Rust for something I build for fun.
It will be a shame if new programmers will stay away from C because of all the scaremongering regarding the consequences of not freeing some memory (in some toy, pet project) in their own computers.
Yes, Rust does not guarantee that it'll prevent memory leaks. But the design of the language does make it harder for you (and your collaborators/dependencies) to accidentally leak memory compared to, say, C++.
> Programming Rust does not mean I have to: buy into their marketing hype
> give the same smug lectures about "safety"
I'm often confused reading articles like this, which take for granted the existence of some "rust evangelism strike force" which goes after people on the internet for not liking rust enough.
The way people talk, it sounds like there's some insanely effective marketing campaign going on to promote rust everywhere. But I haven't seen it. Certainly not any more than any other technology people get excited about for awhile, like Go. Or docker when that launched.
Where are these comments? Can anyone give some actual links to these sort of comments people say online, which don't get immediately downvoted? The way people talk, these comments must be made in such large volumes that it seems very odd I don't notice them?
It's way rarer on Hacker News than people alleging an omnipresent Rust Evangelism Task Force is constantly imposing itself on people. I have seen "overly enthusiastic" comments about Rust, but I can count them on one hand. I'm not going to link them because I don't want to dogpile ob people. Note that I read many/most of the Rust threads that make it to the front page.
But I have seen thousands of comments complaining about these supposed evangelists (no exaggeration). Less often and less reliably in the past few years, the meme is petering out. But there's absolutely no comparison of the relative frequency. People complain bitterly about Rust on this forum consistently, actual Rust zealots appear very rarely.
It is simultaneously true that Rust is "just a tool" and that this is a significant fact, and that the people complaining about Rust are the bigger problem in the day to day discourse in Rust related threads on this platform and in the present day.
I think it's an old stereotype. When Rust started gaining popularity, I did see comments like that. Even felt compelled to post them sometimes. But now that we have real production Rust experience, we're a bit more nuanced in our views.
Post anything negative about rust, or anything about a severe bug in some non-rust code, for examples of your own
I have nothing against rust, although the learning curve is too steep and development in rust is too slow to be a practical general purpose language for a regular company.
The culture around dependencies also means you pay for your memory safety by increased supply chain risk.
Golang or Java gets you memory safety, faster compilation, easy hiring and have better standard libraries
I think it's just what happens when something genuinely great comes along. Some people try it and enthuse about it. Sometimes other people who haven't tried it assume that it's just like all the other average things and therefore the only explanation is irrational fanboyism.
We saw the same thing with the iPhone. It was a step change from previous phones. Loads of people were like "it's just Apple fanbois, I'll stick to my N95" without even trying it.
All technology is just a tool, unfortunately it turns into religion like behaviours, because it defines with whom we work, what projects we can work on, what CVs get through HR and which ones don't,....
The horror of picking tech working in it 10 or 15 years and then it suddenly becoming obsolete or irrelevant. Is something a lot of people can relate to.
It’s useful to align groups on underlying philosophies about problem solving and what tooling we will use.
The alternative is way slower and less effective. “Just use whatever language and frameworks you want and solve the problem in a vacuum” would be a nightmare for any team trying to ship.
A programming language is a medium to communicate programs to something that can execute them. That isn't exactly the same thing as a tool. A tool in my book is a metaphor for a program that helps achieve some well-defined task. Even if we ignore this difference, we would still want to talk about tool safety.
In my experience there is a C++ mob that hates Rust. These are the people who declare statement of facts as ideology. No good faith dialogue is possible.
There are also competent C++ programmers who misunderstand or don't know how static checking works.
I also witness normal people who are completely surprised by a statement like "C++ is all unsafe" and find that too strong. Using the word "safe" with a technical meaning throws normal people off because, sadly, not everyone who writes code is an academic PL researcher.
"Safe", in Rust and much PL research, means "statically checked by the compiler to be free of UB". If you are pedantic, you need to add "... under the assumption that the programmer checked all conditions for the code that is marked `unsafe`" for Rust. That is all there is to it. Scientific definition.
C++ in its current form is full of gross design mistakes, many of which could be corrected at the price of breaking backwards compatibility. Mistakes happen, aldo to world leading PL researcher (the ML language and polymorphic references) which is why the field embraced mechanically checked proofs. The difference is the willingness to address mistakes.
Academics use "safe" in exactly the meaning the Rust community uses. If you don't understand this, go and educate yourself.
Academics need to communicate effectively which leads to technical meanings for everyday words or made up words and jargon.
Maybe a statically checked safe low-level language is marketing genius. It is also a technical breakthrough building on decades of academic research, and took a lot of effort.
Bjarne and friends chose a different direction. Safety was not a design goal originally but doubling down on this direction means that C++ is not going to improve. These are all facts.
Backwards compatibility is a constraint. Constraints don't give anyone license to stop people who don't have those constraints.
We don't have to feel any moral obligation to use statically checked languages for programs. But claiming that static checking does not make a difference is ignorant, and attaching value to one's ignorance certainly seems like an indicator for ideology and delusion.
Rust is cool but there is way too much dogma around its memory safety and static typing in general being a panacea. Most errors are not type errors. Two days after Cloudfare's little Rust hiccup that took the internet down for a day I saw people posting about Rust "if it compiles it runs".
If it helps finally acknowledging basic stuff like bounds checking matters, great, this from a guy that rather use system languages with automatic resource management.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
From 1980!
C++26 will finally have hardening on the standard library, something that I could already enjoy in 1990's with Turbo Vision, OWL, MFC, VCL, but was too much to ask for on the standard library apparently, even if compilers kept having each own their approach.
It took governments and companies to start mapping CVEs to money spent fixing them, to finally acknowledge something had to change.
Meanwhile on C land, business as usual regarding Hoare's quote.
I actually don't think this is true. I do think that most programming errors are type errors, in the broader sense of one part of a system making one set of assumptions about the properties of some data, that aren't shared by another part of the system; and that would've been caught automatically by sufficiently sophisticated static correctness checking. I do not think that Rust has a maximally sophisticated type system (nor is it trying to), and while this is reasonable for Rust as a project to decide, I do expect that there will be languages in the future that do more complex things with type systems that might supplant Rust in some domains.
The Cloudflare incident was caused by a confluence of factors, of which code written in Rust was only one. I actually think that Rust code worked reasonably well given the other parts of the system that failed - a developer used unwrap() to immediately crash instead of handling an error condition they thought would never happen; when that error condition did happen the Rust program crashed immediately exactly as expected; and if Cloudflare decided that they wanted to ban not handling an error like this in their codebase, it's a pretty easy thing to lint for with automatic tooling.
If you follow good strong typing principles, you can ensure that most errors are type errors. Yaron Minsky’s phrase, “Make illegal states unrepresentable”, captures this. But it doesn’t happen by accident just because you’re using a strongly typed language.
Also, if Cloudflare had run the standard Clippy linter on their Rust code, and taken the results seriously, it would have prevented the issue you referenced. Static checks don’t help if you ignore them.
With a sufficiently strong type system all errors are type errors! Rust doesn't have that of course, but it does have quite a strong type system so this is a very bold assertion with no evidence.
Rust does have an "if it compiles it works" feel. Nobody means that literally (this should be really obvious). They just mean that once you get it to compile the chance that it works first time is quite high (like 20% maybe?) compared to most other languages where it's more like 1%.
It's just a tool. But to some people, Rust is more like a religion than a tool and they let it define them to the point even the language maintainers disavow them.
At any point, if you provide any conterpoints or fair criticism towards the language objectively, just expect lots of fans to remind you that it is the best programming language ever created and yours is "unsafe" by default.
Sometimes when you have a really good tool, you want to share it.
This was the case with Linux for many people over many years.
FWIW I agree that the community has some frustrating elements, and that its a lot of dogma in comments, though I actually think that’s a fringe element.
> At any point, if you provide any conterpoints or fair criticism towards the language objectively, just expect lots of fans to remind you that it is the best programming language ever created and yours is "unsafe" by default.
This is mostly just a disagreement about what the word "unsafe" means in this context?
"safe" and "unsafe" in the sense Rust uses them aren't a moral judgment about a language, it's a specific (and limited in scope) feature of the language, where memory safety is enforced by the compiler.
Rust has nothing new (even the lifetime stuff is copied) really. It just marketed itself really well. It got a huge number of migrants from JS/TS ecosystem, and python, and some from the C(+*) ecosystems.
Its a good language dont get me wrong, but also a huge pita to work with.
> Rust has nothing new (even the lifetime stuff is copied) really.
Rust has nothing new by academic standards, and this is an explicit goal of the project. (And that's why it has yet to support e.g. Haskell-like higher-kinded types; or dependent types for compile-time programming: the interaction with its low-level featureset is very much an open question.) It's incredibly novel as a production language, of course.
It has nothing new but they did a good job at cherry picking what what nice in other languages.
Which makes it an interesting language to learn actually. I even feel like Rust can even be a superb first language to learn for a new programmer : that’s a journey for sure but it would expose you to most of the modern programming concepts.
Saying it has nothing new seems like an uncharitable take. Yes, it has influences (that rust docs dedicate a page to [0]), but PL theory has such a rich body of literature that you can make a similar claim about virtually any language. It's the whole package that matters, and I don't think there's anything "rust but earlier" to point to there. Certainly isn't Ada.
Rust is a very very ugly language, this is made worse when it is shamelessly promoted by bunch of persistent people with bad tastes.
Also trying to fight runtime behavior with compile time constraints cannot be a universal treatment. Trying to enforce OOP is one of such examples, and it already failed .
We may disagree on the premise that humans are generally incapable of correct and safe manual memory management, but that's a degree of distrust I hold for myself. You may have never written a memory bug in your life, but I have, and that renders me completely incompetent.
If a project in an unsafe language has ever had a memory bug (I'm looking at you, Bun), the maintainers objectively have a track record of not being capable of manual memory management. You wouldn't put a person who has a track record of crashing busses at the wheel of a school bus.
And Rust isn't the only memory-safe language. You can turn to Java, Go, C#, Type/JavaScript, and whole bunch of others. Rust just so happens to have ocaml tendencies and other things that make it a joy to read and write, so that's definitely preference on my part. One of these days I'll learn ocaml and possibly drop Rust :)
This feels overly binary. Memory management bugs is just one class of bugs, and there have been many other bugs leading to security issues or defects.
If you apply the standard "has ever written a bug" → "completely incompetent" you will have to stop using software, and if you think about it most other technology too
Memory safety is a very useful trait for a language though, and as you say provided by a whole bunch of different languages nowadays
It's a particularly bad one though because it always leads to UB, which means you can't say anything about what happens next.
That's why memory bug severity is often "MAY lead to RCE but who knows". At least with non-UB bugs you can reason about them.
In any case, Rust massively helps with logic bugs too. It's not just about memory safety.
This is also why memory safety is table-stakes when it comes to formal verification of the underlying program logic. You can't solve logic bugs (even where that's known to be feasible, such as for tightly self-contained, library-like features) without solving memory safety first.
If you read a language standard and try very hard to forget that the actual computer exists, sure.
If you remember computers are real, you can pretty easily tell what will happen when you write to address 0x00000000 on a CPU with virtual memory.
For example, you can do a double free, or write to a pointer that was freed.
Welcome to acceptance: https://mohitmv.github.io/blog/Shocking-Undefined-Behaviour-...
Imo the strong point of rust is compile error if you try to use an obj after move (unlike c++ with undef behavior and I guess it should be the same for java/c#), or that you can't modify a container if you hold a ref/pointer to some of it's elements/range which may cause invalidation in C++ case due to realloc
Unless there is some DevOps freedom to at least put something like Sonar or clang tidy on the build pipeline breaking PR that don't play by the rules, and even then you cannot prevent everything via static analysis rules.
Documentation / UT are harder to define (what is good documentation, is UT covering everything?), but usage of manual memory handling can be spotted relatively easy automatically. There can be some exceptions for 3rd party libs interaction if it's absolutely necessary but detecting such occurrences and keeping track of them is relatively easy.
Which in C++ good practices means type safe abstractions not exposing any kind of C style strings, arrays, casts, pointer arithmetic,....
Unfortunely still relatively rare, some of us when we were the C++ Striking Force in the 1990's Usenet flamewars already advocated for such practices, most of them already possible with C++ARM, no need for modern, post-modern, rococo, baroque or whatever C++ style is going on with C++26 now.
Only a handful of apps and frameworks have figured this out. Most of the world moved onto HTML+Javascript plus Electron. Or mobile UI.
Who is using native UI in 2026? GTK and QT don't feel great.
I'm glad Zed is trying. We need more efforts.
Game developers, Windows applications in .NET (possibly with some C++/COM modules)
The problem with native UIs is mostly a Year of Linux Desktop problem.
I discovered cxx-qt which is maintained by some Qt maintainers, which are all employed at KDAB. I had no idea KDAB or this project existed. It's been very smooth so far.
I can honestly say the barrier to building a GUI is very low with Claude, must to the dismay of others, but it beats me building an Electron app.
https://github.com/KDAB/cxx-qt
Swift. Which is similar to Rust in some ways actually.
For me while Go is definitly better than Oberon(-2), and Oberon-07, some of its design decisions are kind of meh, still I will advocate for it in certain contexts, see TinyGo and TamaGo efforts.
As old ML fanboy, you can find such tendencies on plenty of languages not only OCaml. :)
I see Rust as a great way to have made affine types more mainstream, however I rather see the mix of automatic resource management + strong type systmems as a better way forward.
Which is even being acknowledged by Rust's steering group, see Roadmap 2026 proposals.
That's an interesting way to navigate the world. Do you hold this attitude towards other professionals? For example, if a lawyer ever lost a case by misinterpreting a law, they have a track record of not being capable to practice laws and should be disbarred?
There were (and most likely, still are) even memory bugs in Rust standard library[0]. By your logic the standard library maintainers objectively can't handle unsafe blocks.
[0]: https://nvd.nist.gov/vuln/detail/cve-2018-1000657
However, I also don't understand how people don't see the usefulness of what Rust put to the mainstream: algebraic data types, sum types, traits, etc.
I also get super annoyed when people think Rust is only chosen for "safety". Says frustrating things like "so I can just use unsafe", because no you don't and if you do I would reject your changes immediately.
Honestly, in general, I am just annoyed when people don't use the right tool for the right job. And attempts to fix the tool with more bespoke stuff on top it.
This is the kind of hostility (which is frankly toxic) that’s become associated with parts of the Rust community, and has fairly or not, driven away many talented people over time.
But there will be other languages in the future that will continue to deliver small improvements until one day they result in another phase change. The honeymoon with Rust will be over and it will start feeling more antiquated.
C, Python, Java, are just a couple random languages that were/are similarly influential. (C is of course orders of magnitude more influential, the only language more influential is probably COBOL?)
That language may well be Rust itself, especially if they manage to figure out the "how to deprecate standard library features across language editions and allow reuse of their idiomatic syntax?" problem.
CHERI has different characteristics in that it will crash for buffer overflows, but crashing on use-after-free is opt-in, it can only detect double-frees sometimes, it does nothing about uninitialized memory access, etc. It also requires adopting new hardware, which may be a hard sell.
In all I've mentioned above, I haven't even touched thread safety or integer safety which these do nothing about.
So with that being said, do as you please, but understand that simply adopting these is a different level of safety (program will not be exploitable but will crash) compared to something like Rust (program is not exploitable and will not crash because these issues are mostly* compile-time errors).
* "Mostly" since I mentioned integer safety which will be a runtime crash like the C safeguards, you can use unsafe, etc.
I agree, and I'm interested to see what it is in the age of LLMs or similar future tools. I suspect a future phase change might be towards disregarding how easy it is for humans to work with the code and instead focus on provability, testing, perhaps combined with token efficiency.
Maybe Lean combined with Rust shrunk down to something that is very compiler friendly. Imagine if you could specify what you need in high level language and instead of getting back "vibe code", you get back proven correct code, because that's the only kind of code that will successfully compile.
Rust code will be faster, safer, and easier to ameliorate bugs in.
Rust seems like the best language to serialize business logic to now that LLMs are so good at it.
If the LLM makes a mistake in Javascript or Python, you literally won't know until runtime. With Rust, you'll know immediately and have really good compiler recommendations for fixes.
I think Rust is the best LLM language. I am somewhat biased: I've written Rust code for ten years, and I'm having a blast with Claude Code writing it for me instead now. But I've also used so many other tools and languages - enough to say that Rust has some unique advantages here. And also that Claude does a fantastic job emitting Rust.
LLMs emitting Python feels like building with clay. LLMs emitting Rust feels like building well-engineered steel skyscrapers.
But when I learn a better language I will adopt it.
> refuse to admit there are alternatives to RAII
I'm even more curious about this. Can the author or anybody else explain what this means specifically? Can anybody list those alternatives other than GC and RC?
PS: Computer Science isn't exactly my primary professional competence.
Personally I'd prefer writing Haskell but there are sharp edges I can't overlook (like constantly breaking LSP of 11/10 difficulty on producing distributable binaries).
I cringe every time I spit out 50 lines of boilerplate just to get C done Rust, but it's best tool I found that's good enough in many scopes.
I find my experience with Erlang has helped with the (considerable) learning curve for Rust, but I still prefer Go for most use-cases.
The IDE capabilities are not nearly as advanced as they are for Java for example.
Compared to C/C++ or dynamically typed languages, sure.
I love that cargo unifies the ecosystem, no quabble over one shitty build tool over another.
I feel like the IDE story still has a long way to go.
See Visual C++ (with hot code reloading, incremental linking, AI integration, on the fly analysis), QtCreator, Clion (comparable with VS in many options), C++ Builder (with its RAD capabilities),....
Cargo is great as long as it is only Rust code and there is little need to interop with platform SDKs, then it is build.rs fun.
Yea, I get smug judgement from Rust zealots for not picking the in vogue crates.
I get a lot of help too though.
People are passionate about it. That has good and bad outcomes.
It will be a shame if new programmers will stay away from C because of all the scaremongering regarding the consequences of not freeing some memory (in some toy, pet project) in their own computers.
> give the same smug lectures about "safety"
I'm often confused reading articles like this, which take for granted the existence of some "rust evangelism strike force" which goes after people on the internet for not liking rust enough.
The way people talk, it sounds like there's some insanely effective marketing campaign going on to promote rust everywhere. But I haven't seen it. Certainly not any more than any other technology people get excited about for awhile, like Go. Or docker when that launched.
Where are these comments? Can anyone give some actual links to these sort of comments people say online, which don't get immediately downvoted? The way people talk, these comments must be made in such large volumes that it seems very odd I don't notice them?
But I have seen thousands of comments complaining about these supposed evangelists (no exaggeration). Less often and less reliably in the past few years, the meme is petering out. But there's absolutely no comparison of the relative frequency. People complain bitterly about Rust on this forum consistently, actual Rust zealots appear very rarely.
It is simultaneously true that Rust is "just a tool" and that this is a significant fact, and that the people complaining about Rust are the bigger problem in the day to day discourse in Rust related threads on this platform and in the present day.
https://news.ycombinator.com/item?id=47191837 https://news.ycombinator.com/item?id=47191619
Post anything negative about rust, or anything about a severe bug in some non-rust code, for examples of your own
I have nothing against rust, although the learning curve is too steep and development in rust is too slow to be a practical general purpose language for a regular company.
The culture around dependencies also means you pay for your memory safety by increased supply chain risk.
Golang or Java gets you memory safety, faster compilation, easy hiring and have better standard libraries
We saw the same thing with the iPhone. It was a step change from previous phones. Loads of people were like "it's just Apple fanbois, I'll stick to my N95" without even trying it.
In the past I had the impression that some thought that Rust was the first programming language to ever have the concept.
The alternative is way slower and less effective. “Just use whatever language and frameworks you want and solve the problem in a vacuum” would be a nightmare for any team trying to ship.
https://crates.io/crates/serde
https://crates.io/crates/regex
Anything covered by Gjengset's "decrusted" series: https://youtube.com/playlist?list=PLqbS7AVVErFirH9armw8yXlE6...
Sort of on the border between toy and not-toy; Gjengset implements a concurrent hash map: https://youtube.com/playlist?list=PLqbS7AVVErFj824-6QgnK_Za1... [17hr recorded over 3 streams]
In my experience there is a C++ mob that hates Rust. These are the people who declare statement of facts as ideology. No good faith dialogue is possible.
There are also competent C++ programmers who misunderstand or don't know how static checking works.
I also witness normal people who are completely surprised by a statement like "C++ is all unsafe" and find that too strong. Using the word "safe" with a technical meaning throws normal people off because, sadly, not everyone who writes code is an academic PL researcher.
"Safe", in Rust and much PL research, means "statically checked by the compiler to be free of UB". If you are pedantic, you need to add "... under the assumption that the programmer checked all conditions for the code that is marked `unsafe`" for Rust. That is all there is to it. Scientific definition.
C++ in its current form is full of gross design mistakes, many of which could be corrected at the price of breaking backwards compatibility. Mistakes happen, aldo to world leading PL researcher (the ML language and polymorphic references) which is why the field embraced mechanically checked proofs. The difference is the willingness to address mistakes.
Academics use "safe" in exactly the meaning the Rust community uses. If you don't understand this, go and educate yourself. Academics need to communicate effectively which leads to technical meanings for everyday words or made up words and jargon.
Maybe a statically checked safe low-level language is marketing genius. It is also a technical breakthrough building on decades of academic research, and took a lot of effort.
Bjarne and friends chose a different direction. Safety was not a design goal originally but doubling down on this direction means that C++ is not going to improve. These are all facts.
Backwards compatibility is a constraint. Constraints don't give anyone license to stop people who don't have those constraints.
We don't have to feel any moral obligation to use statically checked languages for programs. But claiming that static checking does not make a difference is ignorant, and attaching value to one's ignorance certainly seems like an indicator for ideology and delusion.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
-- C.A.R Hoare's "The 1980 ACM Turing Award Lecture"
From 1980!
C++26 will finally have hardening on the standard library, something that I could already enjoy in 1990's with Turbo Vision, OWL, MFC, VCL, but was too much to ask for on the standard library apparently, even if compilers kept having each own their approach.
It took governments and companies to start mapping CVEs to money spent fixing them, to finally acknowledge something had to change.
Meanwhile on C land, business as usual regarding Hoare's quote.
The Cloudflare incident was caused by a confluence of factors, of which code written in Rust was only one. I actually think that Rust code worked reasonably well given the other parts of the system that failed - a developer used unwrap() to immediately crash instead of handling an error condition they thought would never happen; when that error condition did happen the Rust program crashed immediately exactly as expected; and if Cloudflare decided that they wanted to ban not handling an error like this in their codebase, it's a pretty easy thing to lint for with automatic tooling.
If you follow good strong typing principles, you can ensure that most errors are type errors. Yaron Minsky’s phrase, “Make illegal states unrepresentable”, captures this. But it doesn’t happen by accident just because you’re using a strongly typed language.
Also, if Cloudflare had run the standard Clippy linter on their Rust code, and taken the results seriously, it would have prevented the issue you referenced. Static checks don’t help if you ignore them.
With a sufficiently strong type system all errors are type errors! Rust doesn't have that of course, but it does have quite a strong type system so this is a very bold assertion with no evidence.
Rust does have an "if it compiles it works" feel. Nobody means that literally (this should be really obvious). They just mean that once you get it to compile the chance that it works first time is quite high (like 20% maybe?) compared to most other languages where it's more like 1%.
At any point, if you provide any conterpoints or fair criticism towards the language objectively, just expect lots of fans to remind you that it is the best programming language ever created and yours is "unsafe" by default.
Sometimes when you have a really good tool, you want to share it.
This was the case with Linux for many people over many years.
FWIW I agree that the community has some frustrating elements, and that its a lot of dogma in comments, though I actually think that’s a fringe element.
This is mostly just a disagreement about what the word "unsafe" means in this context?
"safe" and "unsafe" in the sense Rust uses them aren't a moral judgment about a language, it's a specific (and limited in scope) feature of the language, where memory safety is enforced by the compiler.
Its a good language dont get me wrong, but also a huge pita to work with.
Rust has nothing new by academic standards, and this is an explicit goal of the project. (And that's why it has yet to support e.g. Haskell-like higher-kinded types; or dependent types for compile-time programming: the interaction with its low-level featureset is very much an open question.) It's incredibly novel as a production language, of course.
Which makes it an interesting language to learn actually. I even feel like Rust can even be a superb first language to learn for a new programmer : that’s a journey for sure but it would expose you to most of the modern programming concepts.
[0] https://doc.rust-lang.org/reference/influences.html
Also trying to fight runtime behavior with compile time constraints cannot be a universal treatment. Trying to enforce OOP is one of such examples, and it already failed .