Ask HN: Are there any good reasons to use C++ over Rust for new projects today?

Every language has its own merits, there's no single language that's universally the best for every task.

With that said, C++ and Rust both occupy similar domains (high-performance, low-level, often interacts with OS syscalls or hardware).

Pros of C++:

- More mature, excellent library ecosystem, decades of code to reference from.

- Syntax is arguably easier to read and write

- It's very popular (top 6th language on GitHub), lots of talent to hire from.

Pros of Rust:

- Memory safety, it's much harder to introduce bugs of a certain type.

- The borrow checker makes it easier to reason about lifetimes of objects.

- Cargo is great for pulling in libraries (just needs more of them).

For me personally (graphics / game-dev), cost and speed of development is the deciding factor. I use both: C++ by default, and Rust for low-level, safety-critical code.

I understand your hesitation, but I’d really appreciate your take, given you seem to know your stuff.

Personally I think the sibling comment is pretty accurate, and rust is held back by:

- slow compiling of larger projects

- async stuff can quickly lead to very complex shenanigans

- embedded still requires you to write HAL stuff for MCUs that is supported out of the box for C

Existing library support. The rust ecosystem in some domains (Large parts of embedded) are immature. And, (hot take), while generally Rust's syntax is nicer than C++'s across the board (Not having headers, clearer struct and function syntax, array refs vice pointers etc, avoiding scattered/global state), the friction generated by generics and async in some parts of the ecosystem negates them.

So, if you use rust on a given project, you may end up re-inventing things that could be libraries, due to lack of support, or the libraries having missing features or a poor/poorly-documented API. Normally, auto-generated Rust docs are a good way to learn a library, but generics negate it by ending the link trails.

I think you'll find the tooling, and (non-async, non-generic) syntax of Rust are a step up from C++.

I just started a new project in C++ for two reasons:

1. I already know (some) C++

2. more mature GPU ecosystem, particularly CUDA support

I don't mind learning new languages, so CUDA was the deciding factor for me. Maybe someday as Rust's GPU support improves I'll consider a rewrite.

> standards committee or bjarnes, what they're going to tell you is to rewrite it

The same will be true for Rust in 50 years (assuming Rust doesn't die any time soon). If they didn't think it was worth modernizing, they'd just leave C++ alone (which I think they should, but that's another matter).

For old C++, you run valgrind and a linter on it and if nothing comes up it's also "probably fine". At least it's hard for me to think of a situation where the most productive/profitable-for-buisness thing a developer can be doing is modernizing their old C++.