[nivexous]

In Bitcoin SV, there is a saying "devs gotta dev" to refer to the mass of crypto developers that add unnecessary complexity to their coins to solve minor or even nonexistant problems while not seeing the bigger (usually economic) picture. Everyone wants to make their mark on the space and there aren't enough leaders to direct the energy. C++ looks to be doing the same and not able to see the impact this will have on adoption. Oh well. I personally moved from C++ to Rust last year and haven't looked back.

[neutronicus]

I disagree - I work in high-performance computing and I think in our case the complexity of C++ is actually mirroring that of the problem domain. Nothing else gives us the level of abstraction that C++ does, while still offering convenient ways to specify low-level performance semantics.

I think for a while Fortran was pulling ahead for large-scale numerical computing, but the mess of different options for parallelism (and also I think in our case a profileration of algorithm choices that made not just polymorphism but the explicit distinction between polymorphism and templates more important for code architecture) have brought C++ back into the limelight.

I know that some competitors in our space have a Fortran codebase and they essentially had to hack together C++ Templates as part of their build process (i.e. pre-process a template file and generate multiple sources which are then compiled).

[carlmr]

I agree that in your case C or C++ is probably the way to go (I usually favor C, because while it affords less options for abstractions it also doesn't give so many possibilities to shoot yourself in the foot in unimaginable ways (still enough mind you)).

Your parent poster is also right. Rust offers a lot of safety guarantees, a modern, well-designed language around it, package management, test and benchmarking integration, and extremely good type safety, while still mostly having zero cost abstractions for many things. If your goal is performance, control and safety, Rust is a much better choice than either C or C++. I'm still hopeful that it shall become the next big embedded language (mostly processor support missing here, but thanks to LLVM there's hope), especially since we haven't seen any other good attempt at GCless computing (no GC is pretty important for real-time systems).

But I must admit that with C++ you can probably eke out a few % more performance. The thing is though that with Rust, for 99% of projects where performance and no-GC is important, will be fast enough, especially due to safe abstractions, often faster than C++.

One example is if you have a lot of text processing to do. Often you can reuse a lot of the strings. In Rust you can safely handle this due to the borrow checker. Avoiding allocation of new strings is pretty much the biggest performance problem for most string processing.

Rust gives you a lot of safety when it comes to multithreading as well. It's perfect for creating little servers and using all your processors for performance.

These two together, and the lack of 2-3 day debugging sessions where you trace down that one tiny memory bug in C++, make Rust the biggest contender to replace C++. Of course if you only care about performance. C or C++ is probably still a slightly better choice, slightly.

[SamReidHughes]

Looking at some C++ extension proposals, many are definitely a case of "devs gotta dev." Fortunately most of these don't have a chance in hell of making it in.

[VHRanger]

Yeah Stroustrup put his foot down this year on whacky proposals.