People should really know that rust isnt a 100% answer if you want a bug free software. Rust can only prevent memory leaks but it cant prevent logic bugs and parsing errors. Always make sure to debug and review your code carefully....
Something interesting happened when I started to deep dive into rust when I was a 10 years C++ programer. Because Rust has some advantages from the C++ among others, and discarded its flaws, you had to think differently to make you rust program. I had to learn new good practice and new programming design that works for Rust.
Later, when I come back to a C++ project, I saw flaws I built because I had not this knowledge yet. In fact, the rust good practices was like a superset of the old good practices from old programming language, including C++.
My skills clearly step up when I started to do Rust imo
I'd recommend people actually read the article rather than just the headline. It is an interesting analysis of the bugs found during the recent uutils audit. It is actually fairly Rust-positive (rather than using the audit as an excuse to say "Rust sucks actually" like so many other posts).
Rust is literally designed to catch bugs though - the entire borrow checker exists to catch use-after-free, data races, and buffer overflows at compile time. That's not just "developer experience," those are real bugs that cause CVEs constantly in C/C++ codebases.
What’s left is, frankly, a more interesting class of bug. It lives at the boundary between our controlled Rust environment and the messy, chaotic outside world, where paths, bytes, strings, and syscalls are all tangled up in one eternal ball of sadness. That’s the new security boundary of modern systems code.
That's pretty similar to something GKH's said a few times when talking about Rust in the kernel, that it helps prevent tons of stupid little edge cases that plague C, leaving the devs with more time and energy to deal with the actually interesting bugs.
It's a respectable, grounded approach to AI use. I won't let AI code for me (I don't care what FAANG companies are doing, it simply isn't good enough from what I've seen), but it can grok 1,000 lines of code and identify obvious oversights with reasonable accuracy before I can even load the file in my text editor.
Im honestly surprised at how bad the code is? Where the contributors totally blind looking at std::fs module docs?
The race conditions on checking and performing actions on files is understandable, at the end of the day the std lib does not offer most of these presumably due to platform specific behavior (the std has to be general for ALL platforms, including things like microcontrollers). But using Strings as paths? Seriusly?
Some of these behaviors such as "create through dangling symlink" are so evil that somebody should have made an executive decision and removed support for them system-wide ages ago.
I know they are "well known" and people should just not do that but we really shouldn't have to live like this in 2026.
Some of these behaviors such as "create through dangling symlink" are so evil that somebody should have made an executive decision and removed support for them system-wide ages ago.
I know they are "well known" and people should just not do that but we really shouldn't have to live like this in 2026.
I argued in the past for removing setuid bits for similar reasons.
What's the replacement you have in mind? Something like capabilities (basically same thing, just slightly more targeted), or something like dbus services (you need a privileged daemon to delegate permissions to stuff it spawns, but in exchange the unprivileged clients' ability to influence the privileged code is much better scoped instead of all the arbitrary ways a parent can mess with a child process).
Huh, I wonder how much of this could be mitigated by using alternate standard libraries that only allow working with file descriptors or require resolution of certain functions in a attacker uncontrollable context.
The same principle as alternative haskell preludes that remove all partial functions.
isabellium@reddit
Isn't this spam?
the_abortionat0r@reddit
Your comment? Ye.
isabellium@reddit
someones mad ☺️
vaynefox@reddit
People should really know that rust isnt a 100% answer if you want a bug free software. Rust can only prevent memory leaks but it cant prevent logic bugs and parsing errors. Always make sure to debug and review your code carefully....
the_abortionat0r@reddit
This is already a known thing. It's only anti rust people pretending otherwise.
mattias_jcb@reddit
I think most people are aware of this.
6e1a08c8047143c6869@reddit
It prevents memory safety issues, it doesn't (necessarily) prevent memory leaks.
Maybe-monad@reddit
TLDR Rust catches bugs (the ones related to memory at least) but not the ones caused by design flaws in your program.
the_abortionat0r@reddit
And water is wet?
I feel like the only crowd talking about rust magic is the anti rust crowd.
Like, everyone knows bad code is bad rust writers included.
imgly@reddit
Something interesting happened when I started to deep dive into rust when I was a 10 years C++ programer. Because Rust has some advantages from the C++ among others, and discarded its flaws, you had to think differently to make you rust program. I had to learn new good practice and new programming design that works for Rust.
Later, when I come back to a C++ project, I saw flaws I built because I had not this knowledge yet. In fact, the rust good practices was like a superset of the old good practices from old programming language, including C++.
My skills clearly step up when I started to do Rust imo
piesou@reddit
And the design flaws listed in there seem to be more obscure and great to know.
Maybe-monad@reddit
It's domain specific knowledge, feels arcane if you're not a person who interacts with syscalls and low level OS APIs on a daily basis.
TheBrokenRail-Dev@reddit
I'd recommend people actually read the article rather than just the headline. It is an interesting analysis of the bugs found during the recent
uutilsaudit. It is actually fairly Rust-positive (rather than using the audit as an excuse to say "Rust sucks actually" like so many other posts).Akaibukai@reddit
Thanks for the comment as I'll read the article.. Otherwise I was going to say r/noshitsherlock
lKrauzer@reddit
Rust isn't supposed to catch bugs, it's supposed to improve developer experience and diminish memory management efforts
redundant78@reddit
Rust is literally designed to catch bugs though - the entire borrow checker exists to catch use-after-free, data races, and buffer overflows at compile time. That's not just "developer experience," those are real bugs that cause CVEs constantly in C/C++ codebases.
Maybe-monad@reddit
All languages with strong type systems like Rust are supposed to catch bugs but their capabilities are always limited in this regard
TalosMessenger01@reddit
What do you call memory management errors except bugs?
tulpyvow@reddit
me when i dont read the article
yawara25@reddit
reddit moment
Chasar1@reddit
It also helps catching lots of bugs too in my experience. I can't tell you how many stupid Python bugs I make compared to when I write in Rust.
syklemil@reddit
That's pretty similar to something GKH's said a few times when talking about Rust in the kernel, that it helps prevent tons of stupid little edge cases that plague C, leaving the devs with more time and energy to deal with the actually interesting bugs.
StartersOrders@reddit
This seems to be his approach with his “clanker” too. It allows him more time to deal with more difficult bugs.
nullptr777@reddit
It's a respectable, grounded approach to AI use. I won't let AI code for me (I don't care what FAANG companies are doing, it simply isn't good enough from what I've seen), but it can grok 1,000 lines of code and identify obvious oversights with reasonable accuracy before I can even load the file in my text editor.
Compux72@reddit
Im honestly surprised at how bad the code is? Where the contributors totally blind looking at std::fs module docs?
The race conditions on checking and performing actions on files is understandable, at the end of the day the std lib does not offer most of these presumably due to platform specific behavior (the std has to be general for ALL platforms, including things like microcontrollers). But using Strings as paths? Seriusly?
rebootyourbrainstem@reddit
Some of these behaviors such as "create through dangling symlink" are so evil that somebody should have made an executive decision and removed support for them system-wide ages ago.
I know they are "well known" and people should just not do that but we really shouldn't have to live like this in 2026.
Skaarj@reddit (OP)
I argued in the past for removing setuid bits for similar reasons.
rebootyourbrainstem@reddit
What's the replacement you have in mind? Something like capabilities (basically same thing, just slightly more targeted), or something like dbus services (you need a privileged daemon to delegate permissions to stuff it spawns, but in exchange the unprivileged clients' ability to influence the privileged code is much better scoped instead of all the arbitrary ways a parent can mess with a child process).
Skaarj@reddit (OP)
The second one. Having a privileged daemon that has a well scoped API is what I prefer.
Jello_Raptor@reddit
Huh, I wonder how much of this could be mitigated by using alternate standard libraries that only allow working with file descriptors or require resolution of certain functions in a attacker uncontrollable context.
The same principle as alternative haskell preludes that remove all partial functions.
Extra-Papaya-365@reddit
Excellent article! Some very subtle language-agnostic gotchas documented in there...
mina86ng@reddit
umask.