They really are, though. Security is all-encompassing, including not just programming languages, libraries, programs, but also systems, humans and their processes. Don't forget physical security either.
There are no silver bullets, and if the Rust Hype Squad told you there were and all you had to do was buy their product, they were just bamboozling you to push adoption of their pet language.
Write in whichever language you like. Including Rust. Including C. Even PHP. You can write secure software if you put your mind to it.
That's not a great analogy. There are no pick-proof locks (...that are mechanically operated and admit keys; I'm presuming you didn't mean "pick-proof" in that there is no keyhole to pick but is defeated some other way, e.g. a keypad, you meant maximally pick-resistant in contrast to "easily picked")
And honestly? No! If someone can kick your door down, don't waste your money on a super-secure lock, they will just kick your door down. And if you're having your door kicked down on the regular, don't even focus on bolstering the door (they'll either start using power tools or take some other tact like smashing your windows or drilling through the floor or roof). Leave the door open if you like, but move whatever's attracting the attention of intruders somewhere more defensible. Focusing on the securing the wrong thing is also a security flaw!
Ah...these security issues are perfectly cromulent because my shiny new magical beans language let's me screw up in brand new ways, not the old and busted boomer screwups. New is always awesome.
How many CVEs in coreutils over the years? The project has the advantage of being old enough for them to be fixed. Call me when the rust rewrite has been there that long and still has more CVEs than the GNU counterpart.
Maybe coreutils is so old that most security vulnerabilities was solved before CVE even existed. But I think this is also a good argument why we are replacing a solid piece of C code to Rust just because it is "memory safe" and then have lots of CVEs related to things like TOCTOUs (that Rust will not save you).
I'm not against rewriting it in Rust because I believe it really may help in certain class of bugs, but indeed it should not be replacing the old version instantly for that reason. Both could co exist, even tho you still need some guinea pigs to test it out and find issues.
Other than security, Rust brings major improvement to the tooling and may help bring fresh members that wouldn't want to contribute to C code. I understand why some projects go that route
> Other than security, Rust brings major improvement to the tooling and may help bring fresh members that wouldn't want to contribute to C code. I understand why some projects go that route
But it loses old members who don't program in rust, already know the projects, all the reasons of why "this thing" was done "that way". and introduces a new set of bugs, plus now you have two versions of the same thing to maintain.
People thinking that using a superior tool (on paper) enables them to automatically write better tools than the ones who are battle tested over the years baffles me to no end.
Yes, you can go further, possibly faster. OTOH, nothing replaces experience and in-depth knowledge. GNU Coreutils embodies that knowledge and experience. uutils has none, and just tries to distill it with tests against the GNU one.
...and they get 44 CVEs as a result in their first test.
There was an article posted to HN recently that enumerated bugs in the rust rewrite.
Iirc the bugs had to do with linux system details like fs toctou and other things you'd only find out about in production.
Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs, so that every project doesn't have to relearn them at runtime. But the rewrite isn't pure downside.
I'm personally not against Rust rewrites in principle. But doing them in this drive-by hostile manner, esp. with non-GNU licenses smells "hostile takeover" for me, and dismantling core free software utilities is not nice in general.
> Ideally we'd have a better way of navigating platform idiosyncrasies or better system APIs
I believe trying to make something idiot-proof just generates better idiots, so I prefer having thinner abstractions on the lower level for maintenance, simplicity and performance reasons. The real solution is better documentation, but who values good documentation?
Graybeards and their apprentices, mostly from my experience. I personally still live with reference docs rather than AI prompts, and it serves me well.
My read on those was basically that the classic filesystems are hopelessly broken and we need ACID guarantees in the next-gen filesystems, like 20 years ago.
Not saying all of them were about FS TOCTOU bugs but once I got to these, that was my takeaway.
Obviously just using Rust cannot fix _all_ bugs, and I reject any criticisms towards Rust rewrites that tear down this particular straw man (its goal being to make it impossible to argue against). That's toxic and I get surprised every time people on HN try to argue in that childish way.
But if we can remove all C memory safety foot guns then that by itself is worth a lot already.
Losing decades-old knowledge on how the dysfunctional lower-level systems work would be regrettable and even near-fatal for any such projects. That I'd agree with. But it also raises the question on whether those lower-level systems don't need a very hard long look and -- eventually -- a replacement.
I like rust as a language, but boy, the violent, zero-sum proselytising gets on my nerves. It's not enough for Rust to win, but C must be beaten to a pulp and its head mounted on a pike.
New projects wearing an another project's skin have always bothered me - regardless of language. Ubuntu did a similar thing way back with libav masquerading as ffmpeg.
How dramatic. I'll ask you as well: any proof for those colorful pictures you're drawing? Or are the people advocating for Rust a convenient target to vent other, very likely completely unrelated, frustrations?
I'm very happy to work with multiple programming languages without getting religious about any of them. They all have drawbacks, Rust included of course.
However, just my mere skepticism about the existence of the "violent proselytizing for Rust" of course immediately had me put in some imaginary group of fanatics. Which is of course normal. People love their binary camps and nuance and discission about merits be damned.
> The project has the advantage of being old enough for them to be fixed.
That's exactly the point though - replacing established projects is inherently risky no matter how many safety buzzwords the replacement can cram into its GitHub tags.