Performance, breadth/depth of existing libraries, C-interop, and flexibility to name a few.
Not saying you HAVE to use C++ for those reasons, but depending upon your requirements the usability of Go or the robustness of Rust may not be enough to close the capability gap with C++.
Are Go or Rust lacking in performance? Not rhetorical. I don't know the answer to this.
C++ tries very, very, very hard to be as performant as possible; trying to leave no room for devs forced to consider using different languages to eke out more performance. That's one of the reasons that C++11 introduced move semantics in the form of rvalue references, despite how much of a burden it imposes. Without rvalue references, there was a critical disadvantage that C++ had against other languages like FORTRAN. And one of the reasons that the C++ standard leaves so many parts of the language declared as "undefined behavior" or as "platform specified behavior". C++ is not a hand-holding nanny language! The C++ knife is very sharp, and devs can easily cut themselves if not careful.
Granted, C++ does have a vast variety of existing libraries / frameworks / SDKs covering all sorts of problem domains. For example, Boost is a smorgasbord of functionality.
Rust interops with C. Go interops with C.
Ironically to me, C++ interops with C, but C++ does not interop with C++.
By that I mean if I have C++ compiled with GCC g++, and C++ compiled with Visual Studio's CL.EXE, unless the two halves bridge through a C ABI barrier they won't interop. And even if I use a specific version of GCC g++, different compiler flags can make different parts of the code C++ ABI incompatible with one another. In practice, it is merely a bit of a bother and just takes the dev to pay a little attention to avoid the pitfalls.
The reason so many languages interop with C is that the C ABI is well established.
Are Rust and/or Go inflexible? Also not rhetorical, I don't have enough practical experience with Rust and Go to decry either of them as inflexible. I've only written small programs with them, for educational purposes.
Clearly I was not clear enough about what I was trying to communicate 😀
When I mentioned requirements a large part of what I meant was the cutting yourself problem you mention. Even modern C++ is not particularly forgiving so you need to have a clear evaluation of whether that cost and risk are worth it for you.
I also probably shouldn't have used the term interior. My bad. Compatibility is probably a better term, since C++ can literally #include C code. Yes, it will be compiled differently but depending upon what you are trying to reuse that could be better.
The performance angle is a tricky one. Various benchmarks I've seen have C++ > Rust > Go. Are they artificial? Is there difference due to the current optimisers instead of inherent language design? Given the skill set could you have people who could write faster Rust programs than C++?
I think the answer to all of those questions is maybe?
For flexibility, the only thing that Go lacks is templates/generics and that's being worked on. For Rust I've had discussions with colleagues who write high performant C++ for a living, where I asked their opinion of if it could live up to its promise of providing the same performance with better safety. Their assessment, which could be biased, is that for Rust code to match the same performance your have to use so much unsafe code that you lose the benighted is it being Rust.
I thought your prior post and this follow-up post are very good.
Provocative statements, which made me think about things. Those things I posted about, prior. And a nice follow-up answering my non-rhetorical questions. :-)
I'm a programming languages wonk. However, I don't have enough practical experience with Go or Rust. I have decades of practical experience with C++, and profess a love-hate relationship with C++.
In my experience, 95% of most AAA-titled programs can be written in a "safe" language. The 5% of the program that has to be absolutely as performant as possible can be written in an appropriate highly performant language.
My current project is 80-90% C++, if one counts lines-of-code. But all-in-all, it uses about 30 different languages. (I consider C, C++, Objective-C, Objective-C++ as different languages. I consider EcmaScript 3, EcmaScript 5, EcmaScript 6, ExtendScript, ActionScript as different languages. I'm considering pre-standard C++, C++98, C++11, C++14 as the same language. I consider DSLs such as GLSL as a different language.)
A different team wrote 95% of their highly performant AAA-title program in a scripting language. The last 5%, the performant core, was written in C (...but only because the principle developer for that last 5% loves C and loathes C++).
Right tools for the job. Alas, most projects use the tools that are most familiar rather than most suitable. And yes yes yes, familiarity with a language by the dev team is a point in favor of that language as being suitable. But only one point. Developers can pick up a new language, ramp up and become productive in it in a very short order - a few months. I've seen that over-and-over again.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Performance, breadth/depth of existing libraries, C-interop, and flexibility to name a few.
Not saying you HAVE to use C++ for those reasons, but depending upon your requirements the usability of Go or the robustness of Rust may not be enough to close the capability gap with C++.
Are Go or Rust lacking in performance? Not rhetorical. I don't know the answer to this.
C++ tries very, very, very hard to be as performant as possible; trying to leave no room for devs forced to consider using different languages to eke out more performance. That's one of the reasons that C++11 introduced move semantics in the form of rvalue references, despite how much of a burden it imposes. Without rvalue references, there was a critical disadvantage that C++ had against other languages like FORTRAN. And one of the reasons that the C++ standard leaves so many parts of the language declared as "undefined behavior" or as "platform specified behavior". C++ is not a hand-holding nanny language! The C++ knife is very sharp, and devs can easily cut themselves if not careful.
Granted, C++ does have a vast variety of existing libraries / frameworks / SDKs covering all sorts of problem domains. For example, Boost is a smorgasbord of functionality.
Rust interops with C. Go interops with C.
Ironically to me, C++ interops with C, but C++ does not interop with C++.
By that I mean if I have C++ compiled with GCC g++, and C++ compiled with Visual Studio's CL.EXE, unless the two halves bridge through a C ABI barrier they won't interop. And even if I use a specific version of GCC g++, different compiler flags can make different parts of the code C++ ABI incompatible with one another. In practice, it is merely a bit of a bother and just takes the dev to pay a little attention to avoid the pitfalls.
The reason so many languages interop with C is that the C ABI is well established.
Are Rust and/or Go inflexible? Also not rhetorical, I don't have enough practical experience with Rust and Go to decry either of them as inflexible. I've only written small programs with them, for educational purposes.
Clearly I was not clear enough about what I was trying to communicate 😀
When I mentioned requirements a large part of what I meant was the cutting yourself problem you mention. Even modern C++ is not particularly forgiving so you need to have a clear evaluation of whether that cost and risk are worth it for you.
I also probably shouldn't have used the term interior. My bad. Compatibility is probably a better term, since C++ can literally #include C code. Yes, it will be compiled differently but depending upon what you are trying to reuse that could be better.
The performance angle is a tricky one. Various benchmarks I've seen have C++ > Rust > Go. Are they artificial? Is there difference due to the current optimisers instead of inherent language design? Given the skill set could you have people who could write faster Rust programs than C++?
I think the answer to all of those questions is maybe?
For flexibility, the only thing that Go lacks is templates/generics and that's being worked on. For Rust I've had discussions with colleagues who write high performant C++ for a living, where I asked their opinion of if it could live up to its promise of providing the same performance with better safety. Their assessment, which could be biased, is that for Rust code to match the same performance your have to use so much unsafe code that you lose the benighted is it being Rust.
I thought your prior post and this follow-up post are very good.
Provocative statements, which made me think about things. Those things I posted about, prior. And a nice follow-up answering my non-rhetorical questions. :-)
I'm a programming languages wonk. However, I don't have enough practical experience with Go or Rust. I have decades of practical experience with C++, and profess a love-hate relationship with C++.
In my experience, 95% of most AAA-titled programs can be written in a "safe" language. The 5% of the program that has to be absolutely as performant as possible can be written in an appropriate highly performant language.
My current project is 80-90% C++, if one counts lines-of-code. But all-in-all, it uses about 30 different languages. (I consider C, C++, Objective-C, Objective-C++ as different languages. I consider EcmaScript 3, EcmaScript 5, EcmaScript 6, ExtendScript, ActionScript as different languages. I'm considering pre-standard C++, C++98, C++11, C++14 as the same language. I consider DSLs such as GLSL as a different language.)
A different team wrote 95% of their highly performant AAA-title program in a scripting language. The last 5%, the performant core, was written in C (...but only because the principle developer for that last 5% loves C and loathes C++).
Right tools for the job. Alas, most projects use the tools that are most familiar rather than most suitable. And yes yes yes, familiarity with a language by the dev team is a point in favor of that language as being suitable. But only one point. Developers can pick up a new language, ramp up and become productive in it in a very short order - a few months. I've seen that over-and-over again.