Rust’s standard library was vulnerable for years and nobody noticed

Unless you have to type “Please enable maps even though it will break all of my code” every time you run it, that's a distinction most people will ignore. If something is useful enough to ship, people will want to use it — helping test it is even the point — and only the most prominent “This is terribly unsafe” warnings will be heeded.

This article casually throws around definitions of 'memory safety' that are massively different.

Rust's 'memory safety' guarantee is different from Go's 'memory safety'. Rust includes protection from things like modifying memory from 2 different spots at the same time, among other things.

AFAIK that's perfectly fine to do in Go, you can pass around pointers between threads as much as you like. This sort of behaviour wouldn't be allowed in safe Rust.

edit: I just really don't understand the criticism against Rust here for having 'unsafe' given much of what is covered in those unsafe blocks is allowed in many other languages, including a language mentioned in the article as being 'safe'

Good rust code doesn't have to be free of unsafe blocks. In some cases you can't avoid them, e.g. when doing memory mapping. Instead, the unsafe blocks semantically designate areas you should keep an eye on. I rather have 20 unsafe one-liners surrounded by safe wrappers in a project with several thousand LOC, than a 1k LOC C project where I have to take extra care with every step.

> I just really don't understand the criticism against Rust here

I think you are confusing two different narratives in the article: software development in general, and Rust the language/ecosystem/community.

The article raises many points about how the former as a whole does not care enough about security. How we do not have the right incentives to fix memory safety bugs (the bug bounty thing) nor treat them as the security risks that they are (the pushback from developers when you explain that something is a security issue).

That is the software industry in general though, not Rust.

There is also constructive criticism about how Rust handles these things and how it could do better. But it is clear that the author loves Rust for trying to find ways to fix this and how it aims to be a more secure and safe language. Note how the article is full of praise for how the Rust community responded to his feedback, and for the ambitions of the language.

EDIT: as I wrote in another comment, the main point regarding Rust is that "unsafe" by definition throws safety guarantees out the window, so to minimize the risks it brings, solutions outside of the language are needed (aside from hypothetical language improvements that reduce the need for unsafe, of course). This is easily forgotten in the hype about Rust's safety guarantees. Saying "but all languages screw this up in some way" is not really an excuse.

The opposite is true: new vulnerabilities can be introduced in new feature releases, while older releases can receive backported security fixes.

That means that the level of security of a well maintained stable release train can only increase over time.

This is why Debian puts so much effort in freezing and baking the distribution and backporting security fixes.