[oscargrouch]

Heartbleed happen because the open source software used by everyone were left getting dust, with low maintenance and despite its popularity, nobody was paying or donating nothing to keep the project going.

Even if Rust was invented in the 80's, and such a project was in it, the same could happen in one of those unsafe{} blocks a Rust project like this might need to use (and we are forgetting all the ordinary bugs even in the safe portions of the code).

Sure, being in C might be a part of the problem, and this is a good space for tools like Rust to occupy more space, but there's a bigger picture or else Linux would be breaking all the time, and its a solid, big and complex piece of software that works pretty well because there's a lot of economical incentives to keep it going.

[pdimitar]

Answering to another point separately because my other comment grew large enough already:

> or else Linux would be breaking all the time, and its a solid, big and complex piece of software that works pretty well because there's a lot of economical incentives to keep it going.

It is solid... as far as we know. Truth is, nobody is fuzzing the Linux kernel 24/7 except maybe the worst possible actors like national intelligence agencies or malevolent hacking groups -- and they of course would never share and help fix a zero-day because it can help them make money by exfiltrating sensitive information and/or breaking in protected networks.

Don't get me wrong, I admire the Linux kernel devs. They are a standing tribute to all ideas of free and open source and open project management. But Linus himself said security isn't the first priority of the kernel which already means that certain potential problems in the code are being overlooked in favor of speed and stability.

(There was a story some weeks ago on HN showing that there was a pretty nasty exploitable bug in the Linux kernel but I lost the link.)

[pdimitar]

> with low maintenance and despite its popularity, nobody was paying or donating nothing to keep the project going.*

There probably is a Wikipedia page describing this phenomena but I'll settle for calling it "the commodity effect": when something is very widely used then everybody assumes it has been improved to perfection and that it has no flaws (this is not exclusive to software engineering, it happens in many areas of life).

> the same could happen in one of those unsafe{} blocks a Rust project like this might need to use

Sure but they are much easier to search for and audit (like with e.g. `cargo-geiger`). That by itself is a win. Whereas C/C++ needs a special class of linters and scanners, a good chunk of which are paid (a deal-breaker for many software devs not because they're poor but because they don't want to pay for them out of their pocket, and their employer is blind to see the added value and buy those tools for them).

> and we are forgetting all the ordinary bugs even in the safe portions of the code

Only people with agenda forget about those. I worked with Rust in 3 companies in total so far and I've only seen serious, diligent, hard-working devs with attention to detail and a slight case of efficiency mania. :) And they were very mindful of potential bugs and we wrote a lot of tests of different kinds like acceptance/integration, unit, property, and probably others.

No normal smart developer forgets that memory safety bugs are just one class of all the bugs. Turns out however that those are the most widespread bugs in general so IMO it is sensible to use a language that eliminates them by the mere virtue of compiling your program -- and not using unsafe{} in certain ways.

As another poster said, time and attention are limited resources. By removing memory safety bugs from the picture our brains are now free to pay proper attention to the more subtle bugs.