The fundamental question of engineering any product is what is important to the product, and what can be given up.
C++ is the best solution when performance is a top priority.
I disagree. It is a solution but it might not be the best one. Parallelization using C++ requires good up-front design and rigorous discipline in order not to create a buggy mess. With Rust you just focus on performance (e.g. removing locks, increasing lock granularity if otherwise not possible) and not correctness. This can often result in better performance.
And if the performance of the most important innermost loop is what matters you can try to write it in assembly. This works with both C++ and Rust. This is often the best solution for media code, e.g. codec encoders/decoders, as using vector instructions benefits a lot. And compiler auto-vectorization is still a meme.
The idea that you can't make a good C++ program because it doesn't handle memory for you is just silly. I designed the existing Ford manufacturing test system and it has been running beautifully globally for decades. I can't think of a program that is under more scrutiny than this.
I have never said you cannot make a good C++ program. I believe you need more development time to accomplish that instead. And I do not mean just programming time but mostly testing and bug fixing - exposing code to various inputs, running it through sanitizers and fuzzers, etc.
The fact you say "it has been working for decades" proves my point. The vast majority of bugs have already been found and fixed, thus the software is stable. Would you be able to create something like this from scratch, without exposing it to the global market, and have something as stable as this now?
And yes, I do tend to lump all language features that "do the work for you" into one bucket. I call them black boxes. The idea that you can just rely on a black box is silly. Every BIG program I have been involved with (and as you can see from my example, I have had a few) inevitably requires you to understand things at a very low level.
RUST (and other programs) that attempt to make a coder's work easier by doing things for them, take the flexibility of how to do these things away also.
I hope you are thus using C and manual vtables. These are more flexible than C++ ones (e.g. you can dynamically change a function pointer (if it is allocated in non-const memory), you do not need to pass "this" to all vtable functions, you can store constants in the vtable, etc.).
Honestly, I wouldn't hire a coder that didn't know the difference between a critical section, a semaphore, and a mutex.
And what does that have to do with Rust? Do you really think you cannot have all of these there?
(and I have no idea what is the difference between critical section and mutex, maybe this is a Windows thing I am too Linux to understand)
Same for a process or a thread (and when each is the better choice).
Every programming language I know of discerns between these two. Please, leave the straw man alone.
Many coders just want something that makes their life easier; however, making their life easier by using RUST vs C++ comes at a serious performance penalty (speed, latency, and memory required). There are certainly times when this is OK and your win in time and people outweighs the cost, it isn't true for performance critical applications.
Lol, now you invent performance penalties. Rust can be more efficient than C++ as I stated above. It does not have to. Both are statically-typed compiled languages without garbage collection. The Rust compiler, by default, does not allow you to do dangerous things, but this also enables better optimization. For example, if you have a const reference in C++ you know you cannot modify it (let's ignore const_cast) but others still might (by "others" I mean other functions you might (in)directly call). A Rust const reference cannot be modified - period. The compiler can thus cache the value in a register across function calls and not reload it from memory.
Still, additional runtime checks might inflate the code size and thus penalize performance. How much depends on the algorithm you have and there are ways to adapt them to minimize the penalty. As with C++, you can rework the part of the program that has the highest runtime. You can even resort to using "unsafe" (maybe not directly but using a new safe data structure with unsafe implementation). Rust provides a lot more low-level control than garbage collected languages.
My point was (as others was as well) it's crap like RUST that drags down systems.
And my point is that people dismissing Rust for stupid reasons is what fuels security vulnerability business. Again, I do not trust people that say "I never make mistakes".
[RANT]There is always some new shiny toy in software development. I have seen them come and (sometimes) go.
And old men that dismiss all new technology will be left behind.
Anyone remember SOAP? There was a time when it seemed like EVERYONE was raving about it. Same for RUST today. No one wants to make binary level interfaces .... to hard for the poor mistreated software engineers .
Rust supports protobuf, cap'n'proto and similar. You can make a stable versioned binary interface out of a struct, even without external software to generate code (thanks to proc macros).
And you can always just declare a C struct and load it from a file. You will have to use unsafe and/or prove to the compiler the memory you map is correct (e.g. proper alignment, no values that are not representable (e.g. bool has 2 valid values and 254 invalid ones), etc).
I see development branching out into 2 distinct fields. Embedded and low level designers (who will continue to use C and C++) and application level programmers .... who will eventually become unemployed by AI programming. This is the ultimate conclusion to making a language that does it all for you.
This comment is funny. Rust is more successful in embedded programming than in application one. The exception is a server backend software, thanks to Rust async ecosystem.
Lots of time spent in Figma lately. Seems like Ui/Ux design is something that people are still better at than AI . [/RANT]