But can't you then set up a system such that if a person only picks one source or a few sources, and that turns out to be bad, that it primarily impacts negatively only themselves? Letting it be their own responsibility?
> When I update the rust compiler, I do so with very little fear. My code will still work. The rust stdlib backwards compatible story has been very solid.
This is not always true, as seen with rustc 1.80 and the time crate. While it only changed type inference, that still caused some projects like Nix a lot of trouble.
Wasn't the F-35 budget "explosion", or overruns, caused in general by mismanagement? But I will not argue that C++ is perfect. Instead, the ttps://en.wikipedia.org/wiki/Ariane_flight_V88 , where US$370 million was lost, with code written in Ada, is an example where Ada was presented as a safer language and even mandated in the military industry, but where it turned out less well in practice. Even proclaimed "safer" languages can have catastrophic failures, and one can suspect that they might even be less safe in practice, especially if they need mandates to be picked. Instead of Ada companies or other organizations lobbying to force industry to use their language, maybe it is better if there is free competition, and then the onus is on the software development companies to deliver high quality. Ada has improved since the 1990s, perhaps because it has been forced to compete fairly with C, C++ and other languages. Following that thinking, increased, not decreased, competition should be encouraged.
Your lucky soul analogy argument doesn't make any sense.
People made similar arguments regarding C++ versus Ada. The US military and defense industry even got something like a mandate in the 1990s to only write in Ada.
And using seat belts and wearing helmets do not help in those cases where 'unsafe' is used to take the seat belts and helmets off. And that is needed in Rust in a number of types of cases, such as some types of performance-sensitive code.
And Miri is very popular in Rust. Even if a Rust project doesn't have unsafe, sometimes people still run Miri with it, since dependencies might have messed up their unsafe usage.
> No, we don't. All of the ones we have are heavily leveraged in Chromium or were outright developed at Google for similar projects. 10s of billions are spent to try to get Chromium to not have these vulnerabilities, using those tools. And here we are.
Chromium is filled with sloppy and old code. Some of the source code (at least if dependencies are included) is more than 20 years old, and a lot of focus has been on performance, not security.
Using Rust does not necessarily solve this. First, performance-sensitive code can require 'unsafe', and unsafe allows for memory unsafety, thus going back to square one, or further back. And second, memory safety isn't the only source of vulnerabilities. Rust's tagged unions and pattern matching help a lot with general program correctness, however, and C++ is lagging behind there.
'unsafe' is a core part of Rust itself, not a separate language. And it occurs often in some types of Rust projects or their dependencies. For instance, to avoid bounds checking and not rely on compiler optimizations, some Rust projects use vec::get_unchecked, which is unsafe. One occurrence in code is here:
And there are other reasons than performance to use unsafe, like FFI.
Edit2: ghusbands had a different reply when I wrote the above reply, but edited it since.
Edit3: Ycombinator prevents posting relatively many new comments in a short time span. And ghusbands is also wrong about his answer not being edited without him making that clear.