[incrudible]

> The advantages of a language that is memory safe in practice and also heavily favors correctness in general boosts productivity tenfold in the long term.

Does it though? There are many languages that fit this description, you would choose Rust if for some reason you also need good performance. However, if you heavily interop with C/C++ safety goes out the window anyway, and it probably never mattered much in the first place.

[dureuill]

> There are many languages that fit this description

I find that in practice not, especially if you further limit that to imperative languages. Note that I mentioned memory safe AND heavily favors correctness. In that regard, Rust is uniquely placed due to its shared XOR mutable paradigm. One has to look at functional languages that completely disable mutation to find comparable tools for correctness. Allegedly, they're more niche.

> However, if you heavily interop with C/C++ safety goes out the window anyway

I find this to be incorrect. The way you would do this is by (re)writing modules of the application in Rust. Firefox did that for its parallel CSS rendering engine. I did it for the software at my previous job. The software at my current job relies on a C database, we didn't have a memory safety issue in years (never had one since I joined, actually). We have abstracted talking to the DB with a mostly safe wrapper (there are some unsafe functions, but most of them are safe), the very big majority of our code is safe Rust.

> it probably never mattered much in the first place

It does matter. First, for security reasons. Second, because debugging memory issues is not fun and a waste of time when alternatives that fix this class of errors exist.

[jpc0]

Memory safety isn't a defining feature of rust in any way and with very very simple rules in C++ (no raw loops and not raw pointer access) you can actually just get rid of memory issues in C++.

There are also pretty easy solutions to indexing issues (reading past the end of a array for instance) which you can use at compile time or just by enabling a compiler flag to have that at least hard crash instead of memory corruption. That takes a lot of RCE vulns to simply DOS vulns which is a significant increase in "security".

Memory safety isn't the reason to use Rust. That's already available in well written C++, and many other languages. Doing it easily with a large group of people I would say is an argument for using rust. But then you need to argue why not swift or java or kotlin or golang a or any of the crop of languages coming out that also offers easy to code memory safety.

[dureuill]

> no raw loops and not raw pointer access

- Do these rules allow iterators?

- Under the "no raw pointer" rule, how do you express view objects? For instance, is `std::string_view` forbidden under your rules? If no, then you cannot get rid of memory issues in C++. If yes, then that's a fair bit more than "no raw pointer access", and then how do you take a slice of a string? deep copy? shared_ptr? Both of these solutions are bad for performance, they mean a lot of copies or having all objects reference-counted (which invites atomic increment/decrements overhead, cycles, etc). Compare to the `&str` that Rust affords you.

- What about multithreading? Is that forbidden as well? If it is allowed, what are the simple rules to avoid memory issues such as data races?

> That's already available in well written C++

Where are the projects in well-written C++ that don't have memory-safety CVEs?

[jpc0]

You are actually just arguing for the sake of arguing here.

Rust bases all their data structures on pointers just like C++ does, just because you cannot look behind the curtian doesn't mean they aren't there with the same issues. Use the abstractions within the rules and you won't get issues, use compiler flags and analyzers on CI and you don't even need to remember the rules.

And of the billions of lines of code are you really going to try to argue you won't find a single project without a memory safety CVE? You will likely find more than there are rust projects in total, or are we going to shift the goalposts and say they have to be popular, then define popular and prove you won't have a memory safety issue in a similarly sized Rust project. Shift the goalposts again and say "in safe rust" but then why can I not say "in safe C++" and define safe C++ in whatever way I want since the "safe" implementation of rust is defined by the Rust compiler and not a standard or specification and can change from version to version.

I've agreed already that Rust has decent use cases and if you fall into them then and want to use Rust then use Rust. That doesn't mean rust is the only option or even the best one by some measure of best.

[dureuill]

> You are actually just arguing for the sake of arguing here.

I'm very much not doing that.

I'm just really tired of reading claims that "C++ is actually safe if you follow these very very simple rules", and then the "simple rules" are either terrible for performance, not actually leading to memory safe code (often by ignoring facts of life like the practices of the standard library, iterator and reference invalidation, or the existence of multithreaded programming), or impossible to reliably follow in an actual codebase. Often all three of these, too.

I mean the most complete version of "just follow rules" is embodied by the C++ core guidelines[1], a 20k lines document of about 116k words, so I think we can drop the "very very simple" qualifier at this point. Many of these rules among the more important are not currently machine-enforceable, like for instance the rules around thread safety.

Meanwhile, the rules for Rust are:

1. Don't use `unsafe`

2. there is no rule #2

*That* is a very very simple rule. If you don't use unsafe, any memory safety issue you would have is not your responsibility, it is the compiler's or your dependency's. It is a radical departure from C++'s "blame the users" stance.

That stance is imposed by the fact that C++ simply doesn't have the tools, at the language level, to provide memory safety. It lacks:

- a borrow checker

- lifetime annotations

- Mutable XOR shared semantics

- the `Send`/`Sync` markers for thread-safety.

Barring the addition of each one of these ingredients, we're not going to see zero-overhead, parallel, memory-safe C++. Adding these is pretty much as big of a change to existing code as switching to Rust, at this point.

> Use the abstractions within the rules and you won't get issues, use compiler flags and analyzers on CI and you don't even need to remember the rules.

I want to see the abstractions, compiler flags and analyzers that will *reliably* find:

- use-after-free issues

- rarely occurring data races in multithreaded code

Use C++ if you want to, but please don't pretend that it is memory safe if following a set of simple rules. That is plain incorrect.

[1]: https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines

[jpc0]

A significant portion of the core guidelines you don't need to read and are already dealt with in static analysers. As I said, you don't need to know the rules, enable an analyser and you get the exact same experience as rust, your code won't pass the build step.

And am I going to tell the family of the dead person at a funeral my code failed but it's not my fault, the compiler has a bug and I couldn't confirm that myself? And don't pull the "the code is open source you can look at it" crap, I invite you to go and reason about any part of the rust compilers codebase.

In C++ I have multiple compilers all targeting the exact same standard and if in one of them my code is broken I need to explain that, I also have multiple analysers for the same thing.

Also haven't had a single segfault nor memory corruption not index error because I run santizers and analysets on CI, so all those things get caught in build or in testing just like in rust.

Is it as simple as rust, no, and I've already said that but I get the same safety guarantees and I am in control of the code. There isn't some subset of things I cannot do because the languages' built in analysers determines it too expensive to statically analyse that and they don't trust me as a developer to actually write tests and validate all the preconditions I have documented.