[themafia]

> 70% of bugs in a large mature c++ code base come from memory safety bugs.

Are 100% of those exploitable? This single ended statistic is simply not useful.

> Other types of logic bugs are also easier to avoid in rust because it's type system is quite powerful.

You have proof of this?

> Anyone who's actually migrated a code base from c++ to rust should be able to attest to the benefits.

That's not how these measurements work. In particular, modern C++ has many of the same advantages you just cited, so this claim is dubious in two ways.

And you've entirely failed to address the largess of Rust, which, again, for a "systems language" is entirely mismatched.

[dminik]

> And you've entirely failed to address the largess of Rust, which, again, for a "systems language" is entirely mismatched.

I'm not entirely sure where this idea even comes from. Why would it be desirable for a systems programming language to be sparse on features?

[surajrmal]

Bugs don't need to be exploitable to be a problem. The program is incorrect and invariably will fail to act correctly due to those bugs.

Modern c++ has none of the advantages I mentioned. std::variant is cumbersome to use and you cannot easily match on it exhaustively, std::optional and std::expected have UB if you look at the stored types without checking if it's valid first. I love c++ and still use it daily, but I also know I write more bugs when I use it compared to rust. I don't have hard proof that rust is less prone to other types of bugs but wouldn't be surprised if someone produces a blog post with evidence. If you're trying to make judgement without experience, then that's simply foolish.

I'm not sure why you would point to "bigness" of the language as a problem when you're fine with considering c++ a systems language. If you don't like cargo, you don't have to use it. There are other build tools that can integrate with the rust toolchain the same way you would do so with c++. If some libraries are not suitable, don't use them. There are plenty of c++ libraries like boost which I avoid because they don't work well for me too. Consider the way in which The Linux kernel is using rust the language. The key to whether a systems programming is useful is whether I can meet the constraints the software must run in, typically in terms of binary size, memory usage, and runtime performance. Rust delivers here and can be used anywhere c/c++ have found success.

[Ukv]

> Are 100% of those exploitable? This single ended statistic is simply not useful.

Some more links/statistics (including on 0-days exploited in the wild) here: https://www.memorysafety.org/docs/memory-safety/#how-common-...

> You have proof of this?

One class of non-memory-safety bugs that safe Rust entirely prevents is data races: https://doc.rust-lang.org/nomicon/races.html

> That's not how these measurements work. In particular, modern C++ has many of the same advantages you just cited, so this claim is dubious in two ways.

Are the advantages in those cases (option/result) properly realized when it's just piled on top as something you could do?

I still have to be wary that, for instance, std::strchr could return a nullptr which I might pass on without handling. Plus even with std::optional<T> it's on me to remember to check val.has_value(), else it's undefined behavior to access.

Whereas in Rust, s.find() must return an Option<usize> because there's no null for it to return otherwise, and accessing the inner value (`match`, `if let`, ...) requires handling the Option::None case.

> And you've entirely failed to address the largess of Rust, which, again, for a "systems language" is entirely mismatched.

Large compared to C or Zig, but not compared to C++.