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.
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.