Comment by petcat
6 months ago
At this point I feel like it's no longer an uphill climb to get Rust into foundational, mission-critical code adoption. The benefits are so obvious. Maybe it's just a lingering religious war?
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.
Go look at the comments on any Phoronix article involving Rust in any way and you'll see that it's 80% rust haters making all the same arguments every Rust hater makes. You can implement the same safety features in C++ and assembly if you know what you're doing! You can still write bugs in Rust! I know someone who tried to learn rust and he accidentally deleted his home directory so everyone may as well stick to C!
It's all nonsense, but it would be hilarious if it weren't so ignorant.
The irony is that those haters have been doing the same speech since Ada, Modula-2 and Object Pascal early days.
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.
>It's all nonsense,
How is any of that wrong?
It's all correct and also pointless and irrelevant. It all boils down to "Rust doesn't fix every possible problem so why not stick with something that still has every possible problem?"
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.
1. You don't know what you're doing - everyone makes mistakes.
2. You can still write bugs in Rust but the point is you are far less likely to.
4 replies →
On the sense that you can write a Rust compiler in C and use it to program your software in a better language, yes, all of that is correct.
It isn’t wrong, it’s misguided. You can write the same code in a Turing machine, too.
2 replies →
But the approach here is "write new code in rust", not rewrite.
Google rewrote Android's Bluetooth stack in Rust.
Also mentioned:
Eh, I don't think it's actually one or the other. Google has taken on rewriting some more problematic components in rust. See for example:
Binder kernel driver: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Media codecs: https://www.androidauthority.com/android-16-in-process-softw...
This is also happening at Microsoft:
> Rewriting SymCrypt in Rust to modernize Microsoft’s cryptographic library
https://www.microsoft.com/en-us/research/blog/rewriting-symc...
Yeah, there's also a freetype replacement https://github.com/googlefonts/fontations
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 ends up being "rewrite it in Rust" because new code includes changes to existing code. A nice thing about Rust is that you can generally rewrite things piecewise there's no need to switch everything at once.
Sure, but at a macro level the approach is still to "rewrite" Android subsystems in Rust. Just slowly.
Rust makes sense in the case of Android, where the kernel and software is rolled by Google. In the same way that Java made sense for a lot of the backend services in 2010s despite its drawbacks before Node and Python got major improvements in speed and compute became cheaper.
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.
This is effectively true in C and C++ though. Show me a nontrivial project in either of those languages that has never had a memory safety issue and I'll show you a project that doesn't look at quality. Even SQlite doesn't meet this bar, despite incredibly skilled programmers and an obsessive commitment to quality.
>Show me a nontrivial project in either of those languages that has never had a memory safety issue
I mean, the linux kernel is a pretty good example. Static analyzers and things like valgrind exist for a reason.
1 reply →
> 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 sense a lack of statistical education here.
If you say that something can happen, then whether to use a tool to mitigiate it should also be qualified. The conversation around Rust is that bugs WILL happen, which is not true.
1 reply →
> There is this dumb belief stemming from lack of proper CS education that any code you write can just randomly have memory safety issues.
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
>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.
1 reply →