In any case, I'm glad we're seeing more and more evidence and case-studies of why "rewrite it in Rust" isn't just a meme.
It's all nonsense, but it would be hilarious if it weren't so ignorant.
Multics got an higher security score than UNIX, thanks to PL/I.
During the USENET flamewar days, they used to call programming with straightjacket languages.
Also note how proudly they keep digging out Brian Kerninghan complains against Pascal, that disregard the dialects have taken out those issues, and that while Pascal was designed for teaching, Modula-2 was already available, taking care of those pain points, designed for systems programming.
How is any of that wrong?
In other words, they're upset that a new thing isn't popular so they're trying to think of any argument against it, but none of their arguments are relevant. Yes, you can still write bugs in Rust; of course you can. What you can't do is write memory safety bugs in Rust, which are a huge proportion of security bugs that occur. Rust gives you a massive decrease in attack surface automatically.
This is ignoring the ecosystem, which is full of better tooling, better library packaging, better testing, and just in general an overall better language, but instead of trying to argue the language on its merits they're trying to argue that it's not perfect so why bother.
I've also heard the same arguments about C++; 'anything you can do in C++ you can do in C!', which is technically true but ignores the fact that if I want to do something C++ does it usually makes more sense to use C++ to do it rather than e.g. trying to hack the concept of objects, private methods, templates, etc. into C myself.
2. You can still write bugs in Rust but the point is you are far less likely to.
They've also seen improvements in developer confidence and onboarding time, but not to the same degree.
I mean if you don't know what you are doing you are going to make mistakes that go beyond memory safety. Look at Log4shell for example.
Just saying "but you can still make mistakes" is dumb and irrelevant and it's kind of disappointing that it's such a commonly bandied non-argument that Google still had to address it in this post.
If people don't want to use the language then that's fine, no problem, but a lot of people do want to use the language because it's just a great language to use as well as having memory safety.
Chromium: Parsers for PNG, JSON, and web fonts have been replaced with memory-safe implementations in RustBinder kernel driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Media codecs: https://www.androidauthority.com/android-16-in-process-softw...
> Rewriting SymCrypt in Rust to modernize Microsoft’s cryptographic library
https://www.microsoft.com/en-us/research/blog/rewriting-symc...
I think they're trying to avoid rewriting things for no reason though. The things being rewritten tend to have a history of security problems or other issues that would be cause for a rewrite even if it wasn't in Rust.
That however is a very niche case where Rust is applicable. The anti-rust people (like me) aren't saying that Rust is bad. We are just arguing against its adoption for everything.
When you see shit like "[...] should be rewritten in Rust because memory safe", it shows that people have no idea what memory safety even is. There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues.
The downsides of Rust is that its ownership semantics are often cumbersome to write, which slows down development. Rust is also still evolving because of the stuff that happens under the hood. And for a lot of things, where network latency is dominant and cpu cycles are spent sleeping waiting for responses to come back, you don't need natively compiled code in lieu of python or node that are way more flexible and faster to develop in.
So in most cases, Rust is not applicable, when you can write perfectly memory safe code faster.
There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues.
I mean, the linux kernel is a pretty good example. Static analyzers and things like valgrind exist for a reason.
[0] https://www.cvedetails.com/vulnerability-list/vendor_id-33/p...
I sense a lack of statistical education here.
lol. this take is hilarious in the face of the article you are commenting on. holy cognitive dissonance.
> The downsides of Rust is that its ownership semantics are often cumbersome to write
skill issue
Lol, this is actually very ironic considering Rust is handholding you because you don't have the skills to write memory safe code.
Like I said in my other posts, Rust makes sense in very niche situations. The article just proves that it works for the niche case where its applicable. That doesn't mean Rust automatically wins.