Something that gets really in my nerve over time now RUST …..
I don’t care if program use Rust, C, C++, C#, Python or fucking BrainDead, but why do people always have the need to point out that something is in Rust.
I think there’s a perfectly good reason for that and it’s a good selling point for the techies imo.
Was it M$ that pointed out that 70% of exploits are due to memory corruption bugs? Apple and Google take it seriously enough to put in MET/MIE hardware chips to fight such bugs. On the software side, Rust is a language that makes such bugs impossible (or very highly unlikely?). It’s also why Rust is now being integrated into the Linux kernel.
Disclaimer: I’m not a Rust dev and never used Rust
Indeed, it’s not a “I code in Rust btw” kind of situation.
It’s mostly to say that it might be safer than your usual tool coded in C, JS or whatever language where you could have a memory overflow.
yeah rust has a pride in it’s memory safe language and now that I think about it, this is actually right it is better than say coding C or JS and then manually trying to mitigate memory corruption or overflow
Pretty much the whole point of using Rust indeed. 
Golang is quite proud of being simple, fast and good for specific kinds of software. Each language has their own thing. 
I code in rust btw
In 2019, some supposed security research organization called “Fish in a barrel” found about 66.3% of vulnerabilities in iOS 12, 71.5% of vulnerabilities in macOS 10.14, and 88.2% of vulnerabilities in the macOS kernel and kernel extensions specifically (excluding the rest of the OS) were memory safety vulnerabilities. I’m not 100% sure on their legitimacy, but I think it’s reasonable to think they are given members like Alex Gaynor (who has 3 high severity CVE credits on GitHub).
Source:
In 2019, Fish in a barrel also made a tweet based on Google’s Project Zero claiming that the known exploited zero-days from 2014 to 2019 were about 81% memory safety issues, with additional percentages per-year. Again, disclaimer on legitimacy of Fish in a barrel, but Project Zero at least is trustworthy, and the spreadsheet is still publicly available for analysis (which I have not done, personally, to be clear).
Source:
In 2019 Microsoft released a blog post (two, technically) showing that every single year from 2006 to 2019, roughly 70% of the vulnerabilities they assigned a CVE in each year were determined to have memory safety issues as their root cause.
Source:
In 2019 Google reported that Out-Of-Bounds Writes, Out-Of-Bounds Reads, Use After Free, and Integer Overflows made up 90% of the high severity vulnerabilities in Android for 2018. Integer overflows are not a memory safety concern, but they were grouped in on the initial report. Looking at the chart, you can clearly see the former three do make up the majority of it, though.
Source:
In 2024, Google reported on progress of reducing these with memory safe languages (ie, Rust), and gave 76% as the number for 2019 for memory safety vulnerabilities specifically (which dropped to only 24% by the time they wrote the post). Last month, they reported on this progress again stating that the percentage had dropped to below 20% for the first time.
Source:
I write Rust. I love it, it is my favorite programming language. I recognize that not everyone does, and that’s fine.
I also recognize it isn’t perfect; the compiler, like any software, has bugs. As of writing this, the rust-lang/rust repository has had a total of 60,546 issues opened.
Of all issues, 10,896 are still open (~17.996%) with the remaining 49,650 being closed (~82.004%).
Of all issues, 612 have the “unsound” label, which typically means some sort of memory safety issue[1].
Of the “unsound” issues, 108 are open and 504 are closed.
So:
- Closed “unsound” issues account for about
- 82.353% of “unsound” issues
- 1.015% of “closed” issues
- 0.832% of all issues
- Open “unsound” issues account for about
- 17.647% of “unsound” issues
- 0.991% of “open” issues
- 0.178% of all issues
Source:
These “soundness holes”, as they are often referred to, are not particularly common. When they do happen, they are a high priority for fixing. They also tend to arise more frequently in experimental features such as min_specialization, which are opt-in nightly-toolchain-only features that are typically under active development and not complete.
Rust is not perfect, but when it comes to memory safety that is its raison d’être[2] (the creator himself said so back in 2016, referring to people trying to find justifications for Rust other than memory safety). I have full faith that every soundness hole will be fixed as soon as possible. Even if not, it presents a clear advantage over languages such as C and C++ in this regard that has led to undeniable improvements in the memory safety space.
Source:
I can’t speak for everyone, but I wouldn’t be surprised if it’s mostly because we (Rust developers) love Rust. So to that end, I guess the question is, “why do people tell others about things they love”? Which I can’t answer. I’m not a psychologist.
It could also be pride, certainly. I’m very proud of Rust. A lot of hard work and love has gone into this language, and it has come very far. Wouldn’t you be proud if open-source software you loved and used daily started getting used and praised by big companies like Microsoft, Amazon, and Google? If they posted reports showing how that software has made significant progress in one of the biggest security issues that has plagued software for decades?
Undoubtedly, some of it is hype. I’d be stupid to deny that. Rust has seen an unfortunate popularity with so-called “web3” developers (cryptocurrencies, NFTs, the like). I do believe there are small but loud minorities within the community who do not really understand what Rust guarantees; they just think “Rust is safe” without any regard for what “safe” means. I believe the majority, however, are not like this; they either do understand the nuance and specifics, or they are actively working to try to understand.
I would also think a sense of community is involved. In my personal experience, most developer communities I encountered growing up were not particularly friendly. They were elitist and secretive; if you weren’t as smart as they were, they’d mock you, and they certainly wouldn’t help you. This might have just been bad luck on my side. I’d believe that. But from my perspective, at least, Rust was a very refreshing change of scenery in this regard. The community is enthusiastic and leaps on opportunities to answer questions and teach others. I’ve never been mocked or made to feel unwelcome. I spent a very long time feeling I would never be able to really contribute to open source because I didn’t know what was going on. Rust projects have, in my experience, a tendency to work very hard to make the new contributor experience as easy as possible to get into. Issues are labeled by their difficulty, whether or not they have a mentor available, whether or not they have minimal test cases, and so on. Various experienced team members also hold “office hours” where contributors can seek help with contributing.
I don’t think I could have ever contributed to the C implementation of Tor. Not because they are unwelcoming, but because I’ve known how serious memory safety vulnerabilities are for years, and with how important Tor is, I don’t think I could bear the possibility of being responsible for some critical memory safety flaw that may have put people in danger. It doesn’t help that whenever I tried to find resources on how to avoid writing such bugs, much of what I found back then was “write better code”, “just don’t”, “use Java instead”, etc. Making mistakes is an important part of learning, but I don’t want to make mistakes that kill people. Knowing the compiler will prevent just about any memory safety issue from arising in safe code and that the community is more than happy to guide me down the right path is what enabled me to try my hand at contributing to projects I never would have otherwise. Instead of worrying that every line of C I write could be an obvious memory safety bug that any “real” developer would have known about, I only have to worry when I write unsafe, and there are plenty of resources and people available to help make sure I do it right (including the compiler - contrary to what I’ve heard some claim, unsafe doesn’t just magically “turn off borrow checking” - the compiler still checks as much as it can).
I’ve seen a lot of people hate on Rust online. Sometimes it is because they see Rust as some sort of political movement, or “woke”. Sometimes they think it’s because Rust is out to end the GPL and free software. Sometimes it’s because they think Rust wants to kill C. Other times, I don’t even know. You know what it reminds me of? People fearmongering over Tor. In both cases, the conspiracy theorist in me says they’re nation-state actors trying to discourage and push back against technology that protects people. The realist in me says it’s probably trolls or people who are genuinely misinformed. But in both cases, it bothers me. It bothers me because people have put a lot of effort into technology meant to protect people and make the world a safer place, and people go out and try to sow doubt about these projects, for whatever reason.
Why does it bother you so much that I, or anyone else, cares about these projects and shares that with the world? How does it hurt you? Projects mention what language they were written in all the time!
The Rust Reference defines
unsafecode which can be misused by safe code to cause undefined behavior as unsound - this means any safe code should be able to do absolutely anything without causing UB in soundunsafe, as I understand it. ↩︎“reason to be” ↩︎
Firstly thank you for your response.
You are the first one that actually goes and makes a helpful comment on my statement.
As I said I don’t care about Rust at all. And I intentionally do not learn Rust instead I try C/C++ to learn the memory management.
But that’s something of the scope of my comment now.
Why does it bother you so much that I, or anyone else, cares about these projects and shares that with the world?
The problem with the headline, that I have, is how it is written. “Rust based […]” as you can see the author puts the word “Rust” first.
It is not about the that he points out that it is written is Rust rather than that he switched the weight of points in the sentence.
As you might know, you can play with a lot of things if you write them and one if the tools you have is the order of words.
As a general rule: The words that come first carry more weight in the sentence.
That’s something with which rhetoricians in literature very much enjoy playing around.
So the author of from phoronix gave – attentively or unattentively – the fact that it was written in rust a higher priority than the fact that it is a tool for Gnomes File Browser for Thumbnails.
This means that the fact that Rust was used is more important than the tool itself.
Edit:
So if he instead wrote “Project aims to provide modern thumbnails for Gnome with Rust” or something similar it wouldn’t be a problem to me.
Offtopic
How long have you been using Rust? I used to write Rust 5+ years ago. Is it more enjoyable now to write, or has not much changed since then?
Thank you for the clarification! I think I understand the issue now. I agree that the focus should be on the project and what it accomplishes (or hopes to) first and foremost. This is something that annoys me too, though I don’t notice it as much in headlines.
Kind of like when projects call themselves “RustWord” or “perfectly-good-project-name-rs”; it’s fine to be proud of the language you used and whatnot, but unless you’re working on something very Rust-specific (such as rustfmt or rustc), I don’t think it should be so much of a focus that it becomes part of the project name. I mean, people can name their projects whatever they want, I just think if your project accomplishes something, it deserves it’s own name.
Offtopic
I’ve had an interest and been learning about it for maybe 3 or 4 years, but I didn’t actually bite the bullet and start writing it until about a year ago. I spent a lot of time putting it off because I always heard about how hard it was, so I suspected there was something that I wasn’t being told that would make the experience much worse than it seemed. When I actually got into it, I determined that was nonsense. I wish I had just tried to begin with.
A lot has changed, but whether or not that makes it more enjoyable to write is a hard question to answer without knowing more about what made it unpleasant to write for you. I find it more enjoyable to write than anything else, but there are still sharp edges.
Macros are still a bit alien to me and generally have worse editor support than the rest of the language. Macros 2.0 might improve the situation but are still WIP (and in general, I’m not very invested in macros; I prefer using const for compile-time nonsense).
Compile times have improved, and for me personally, have only ever been an issue with very large projects on old hardware I have already abused quite a bit. If you’re using older/cheap hardware it could still be an issue. The experimental parallel compiler frontend can help if you compile with nightly, and it seems that the community discovered at some point in the last year or two that you can improve compile times for large projects by splitting them up into many smaller crates.
The worst experience I have when writing Rust is working on other people’s projects when they use alternative build systems. Servo uses mach, Facebook/Meta has their buck2, a handful of projects use make or cargo make. I’ve always found it to be less pleasant than just using cargo build and it annoys me to need to tweak my LSP configuration to work with their projects.
If you have any particular issues you remember, I can try to speak on those specifically