Found this on Lobsters, thought it was an entertaining read. For more context, you might want to read the previous instalment, CVE-2024-YIKES (also linked early on in the post itself).

Saw this on Lobsters, thought Lemmy might enjoy it.

We adopted Rust for its security and are seeing a 1000x reduction in memory safety vulnerability density compared to Android’s C and C++ code. But the biggest surprise was Rust's impact on software delivery. With Rust changes having a 4x lower rollback rate and spending 25% less time in code review, the safer path is now also the faster one.

(Emphasis in original.)

Of course, we should probably take the numbers with a grain of salt here; it's not a controlled scientific experiment, and the estimated vulnerability density for Rust in particular was calculated with a numerator of 1, so it could be way off.

Still, I think it's a good reminder that advocacy for using Rust over C and C++ isn't purely out of some irrational fanboy-ism for the language. The numbers here would have to be extremely off for there not to be a major effect.

Further down in the article:

This near-miss inevitably raises the question: "If Rust can have memory safety vulnerabilities, then what’s the point?"

The point is that the density is drastically lower. So much lower that it represents a major shift in security posture. Based on our near-miss, we can make a conservative estimate. With roughly 5 million lines of Rust in the Android platform and one potential memory safety vulnerability found (and fixed pre-release), our estimated vulnerability density for Rust is 0.2 vuln per 1 million lines (MLOC).

Our historical data for C and C++ shows a density of closer to 1,000 memory safety vulnerabilities per MLOC. Our Rust code is currently tracking at a density orders of magnitude lower: a more than 1000x reduction.

A nice little reminder that clarity is not the same as verbosity. Also has some concrete tips for removing unnecessary verbosity in names, complete with examples. Though in some contexts, I might prefer a name like employeeToRole for a Map<Employee, Role> over the article's employeeRoles.

I think this is a decently interesting consideration in programming language design. When you have things flowing from left to right, not only do you get better autocomplete as per the article, but it's probably also easier to read, and very likely easier to edit (your cursor can simply go in its natural direction instead of having to jump around).

Though this comment on Lobsters points out that left-to-right code under one way of thinking is not necessarily left-to-right code if you approach it with a different way of thinking.

Found this article via a comment on Lobsters for a completely different article. It's not exactly the type of knowledge I see myself using in the immediate future, but I think it's still interesting and educational to think about.

Just wanted to publicly announce this project at this point in time. All the info is on the GitHub page. If you have any feedback, or find any bugs or issues, please let me know in the comments.

An interesting article that lays out a problem and goes through a few different solutions, some of which I haven't thought about much before.

I'm working on a video game in Rust, and I'm running into this kind of modelling problem when it comes to keeping track of the game state. So far I've refactored something that resembles Approach 5 into something that looks more like Approach 3. As I get more confident about the final shape of the data, it (seemingly) becomes a better idea to represent it in a more structured way.

Thoughts? It does feel like there's a lot of things you can do in comments that would be impossible or impractical to do in names alone, even outside of using comments as documentation. There's certainly much more information that you can comfortably fit into a comment compared to a name.

One of the comments in the Lobste.rs post that I got this from stuck out to me in particular:

Funny story: the other day I found an old zip among my backups that contained the source code of game that I wrote 23 years ago. I was just learning to code at the time. For some reason that I forgot, I decided to comment almost every single line of that game. There are comments everywhere, even for the most obvious things. Later on, I learned that an excess of comments is actually not considered a good practice. I learned that comments might be a code smell indicating that the code is not very clear. Good code should be so clear, that it doesn’t need comments. So I started to do my best to write clear code and I mostly stopped writing comments. Doing so only for the very few parts that were cryptic or hacky or had a very weird reason for being there.

But then I found this old code full of comments. And I thought it was wonderful. It was so easy to read, so easy to understand. Then I contrasted this with my current hobby project, which I write on an off. I had abandoned it for quite some months and I was struggling to understand my own code. I’ve done my best to write clear code, but I wish I had written more comments.

And this is even worse at work, where I have to spend a ton of time reading code that others wrote. I’m sure the authors did their best to write clear code, but I often find myself scratching my head. I cherish the moment when I find some piece of code with comments explaining things. Why they did certain things, how their high level algorithm works, what does this variable do, why I’m not supposed to make that change that looks like it will simplify things but it will break a corner case.

So, I’m starting to think that this idea that comments are not such a good practice is actually quite bad. I don’t think I can remember ever reading some code and thinking “argh so many comments! so noisy” But, on the other hand, I do find myself often in the situation where I don’t understand things and I wish there were some more comments. Now I’m trying to write comments more liberally, and I think you should do the same.

I guess that’s a generalization of the op’s idea.