I think C++ is still a desirable coding platform compared to Rust

But the idea that stack overflows are not an issue if you try hard enough and pay attention is not very persuasive. It doesn't take much imagination to see that this principle will falter more and more the larger a project gets and the longer it runs. This remains THE big selling point of Rust to my mind.

12-15 years of C++, 8 years of Rust. I generally used C++ because it was the only tool that could do the job at the time, not because I actually liked it. At best, I had a love/hate relationship with C++.

> 2. For new work projects, do you choose C++ or Rust? Why?

Almost always Rust. The main reasons:

- Cargo is awesome, and the crate ecosystem is incredible.

- I barely trust myself to write rigorously correct C++, despite having plenty of C++ experience and being extremely paranoid about code correctness. And I defintely don't trust most other people to do it correctly. (I have maintained more than my fair share of other people's C++ code, and the average C++ code is buggy garbage.) C++ is like fishing around in a drawer of extremely sharp knives in a dark kitchen; you're going to get cut.

- I trust the average Python or TypeScript developer either to write correct Rust, or to be defeated by the borrow checker. This isn't just the borrow checker—it's also bounds checking on arrays and slices, the choice to panic instead of corrupting memory, the rareness of undefined behavior (and "nasal demons", and irresponsibly aggressive optimizations) in safe Rust, the safe mulithreading support, etc.

However, I would consider using C++ in domains where correctness and security weren't important, and where I wanted to use mature frameworks. Games would be an obvious case!

> 3. For new hobby projects, do you choose C++ or Rust? Why?

Rust. Way more fun, personally. :-) I tend to like using "functional" architectures, so I don't fight the borrow checker much.

> 4. Is there something about C++ that you wish Rust had?

Well, now that const generics are in, I'm pretty happy with Rust's feature set. But for quite a while that was the best C++ feature Rust was missing.

2. I'm retired now, but I would have considered Rust for any greenfield project that didn't have a compelling reason to pick C++ (e.g. mandatory interop with an existing big C++ library).

3. Rust nearly every time. I sometimes use a layer of C++ as an FFI shim, such as when writing a gRPC client/server (the Rust libs there aren't mature).

4. The library ecosystem. Rust's crates.io seems full, but if you scratch the surface it's just a bunch of half-baked hobby projects at v0.x versions. And Cargo (the most popular build system for Rust) has essentially no support for multi-library packages, so instead of something like GLib (a single dep with lots of functionality) it's common to see even trivial programs depending on dozens or hundreds of half-baked hobby projects at v0.x versions.

5. Most of the Haskell/ML-ish functionality, such as traits and proper enums. I'm currently in the middle of a Rust project that's gotten much bigger than I expected (parsers are hard! compilers are hard! zero-copy is hard!), but it's still possible to make progress by leaning heavily on the type system.

I often describe Rust as "a dialect of C++ where the compiler forces Google Standard C++ on the world", or alternatively "the language you'd get if you hired a team of Haskell developers to write firmware".

However, this author, like many, does not understand what safety means.

1. There is much more to safety than memory-safety. Safety is about protecting your invariants. A program that is not safe is a program in which things that happen that are contrary to the intent of the developer.

2. Memory-safety is just one of the many tools in the safety toolbox. Without memory-safety, it's really easy to shoot yourself in the foot. With memory-safety, it's still possible, but you have to work harder at it.

3. Segmentation faults or stack overflows are what happens if you break memory-safety and you are extremely lucky. In most cases, what you get is random memory corruption. Do you really want memory corruption in a trading platform?

4. Security and safety are related, but they are different topics. See https://yoric.github.io/post/safety-and-security/ (self-promotion).