arendjr

Looks like a true case of Stockholm syndrome.

I’m learning c++ via exercism because I’d like to use it for game development and other high performance use cases, and because it’s a good pip for the resume.

I think for game development you don't need to worry about a shortage of C++ opportunities any time soon. Both Unreal and Godot are built in C++ as well as many in-house engines. Similarly, there are other niches where C++ is king and it would decades for that to change.

That said, there are certainly areas where C++ is already being replaced by Rust. Areas where both performance and security are important are the first movers, such as webbrowsers, operating system components, but also things like high-frequency traders (crypto ones almost exclusively use Rust, while traditional ones will move slower).

Personally, I also used to be heavily invested in C++, but I'm happy to have moved to Rust myself. I recently became an independent contractor, and while I would be happy to take contracts involving C++ to migrate them to Rust, I would certainly not start new projects in C++ anymore. But for you, I wouldn't worry about that yet. The experience you gain working with C++ will help you appreciate Rust more down the line. Just keep in mind that at some point you will be likely to be exposed to Rust too.

I’d be surprised if C tooling wasn’t available to provide sufficient proof for a given statically-linked program.

Be prepared to be surprised then. If such tooling was available, why isn't it being used by the projects for whom it matters? Yes, there is tooling available, but all the big parties using them are admitting it's not good enough for them. Those tools help, but they do fail in the "sufficient proof" department.

For some follow-up reading:

• Microsoft: https://msrc.microsoft.com/blog/2019/07/why-rust-for-safe-systems-programming/
• Chromium: https://security.googleblog.com/2023/01/supporting-use-of-rust-in-chromium.html
• Android: https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
• Apple: https://security.apple.com/blog/towards-the-next-generation-of-xnu-memory-safety/

They all share the same basic facts: C and C++ are inherently memory unsafe. If any of them could've "just prove[n] your programs are memory safe", I think they would have.

Even references aren’t safe in C++ though, since there’s no borrow checker. Unless you copy everything or use reference counting types everywhere, you’ll still hit plenty of memory-violating footguns. But at that point, why use C++ at all?

Zig is better than C, but still a far stretch from the memory safety of Rust: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

Go is almost memory safe, but it does suffer from an issue with its thick pointers (type + address) that can cause race conditions to misrepresent the type of a data structure. This can lead to true segmentation faults and out of bound memory accesses, though it will probably be quite difficult (but not impossible) to exploit them.

Zig is better than C, but still a far stretch from memory safe: https://www.scattered-thoughts.net/writing/how-safe-is-zig/ I think Nim is better because it uses a garbage collector and doesn’t have any pointer arithmetic, but I couldn’t find as much on the topic.

Generally, I don't think it really matters how many people are involved for the conflict resolution how many people are editing. There is one person who will reach the server first, and then the other(s) need to apply transformation(s).

But I think in your example the tricky part is when you say "each want to add their item as 3rd in the list because it is a todo list and its place in the list is important". The algorithm will be able to resolve for each of them that their item will come after the 2nd, and before what was originally the 3rd. But it will not be able to put them all on the 3rd position, of course, so it will sort their items and insert them adjacent to one another. So with 3 people inserting simultaneously into the 3rd position, one will end up in the 4th position and one in the 5th.