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