I respect the fact that you have had different experiences than mine, so I'm not going to argue with your assumptions. I've worked on C++ and Java apps at Google scale and in my experience, C++ builds have been no slower than Java builds (with the right tooling, like I mentioned before). But again, there are a lot of infrastructural factors that can come into play that can influence your experience.
Things like fine-tuning GC just defers the problem instead of solving it. Furthermore, C++ being a compiled language, it does in fact run faster than bytecode in production. Again, it's a tradeoff that you may be willing to make but it's a bit extreme to impugn that the tradeoff doesn't exist.
I'm not assuming there isn't going to be a lapse in judgement at any point. In fact, if you want to play it safe, you can just use shared pointers all the time and avoid all the memory allocation risks that you'd otherwise face. In that regard, C++ is no more unsafe than other languages. As a class designer, however, I find it a lot more expressive to be able to further impose constraints on how other programmers use the interfaces I provide to make it harder to use it incorrectly (oreilly.com/library/view/97-things...).
All of these are design choices and tradeoffs, and they are intrinsically subjective in nature. As a result, I am not going to defend C++ any further on this thread. It's a widely popular language with or without your liking towards it.
Thanks for the discussion though, I did learn some new things and it's always engaging to hear other perspectives!
I wanted to slip in a real world example of a very performant GC. GHC, the most widely used Haskell compiler, uses GC in the compiled runtimes and it's designed around the fact that Haskell works with immutable data.
In result Haskell applications easily match other application performance written in lower level language, at times even exceeding their performance, thanks to optimizations that GHC can apply due to highly expressive Haskell typesystem.
C++ was faster when Google search was developed. It's not as simple today. Performance is a more nuanced debate at this level and benchmarks can mislead both ways. C++ is not faster and neither is Java. There are benchmarks that can go either way.
A JIT inlines virtual methods at runtime, that's something a C++ compiler can't physically do. This is one of those super optimizations that can make a frequently used code path scream since it serves as a basis for further, even deeper optimizations. A well tuned GC can place the peek where you have idle time. C++ will pay a higher price usually on the same thread where things physically happen. To be fair a GC typically needs more RAM to play around with, especially with a JIT. It can tradeoff of more RAM vs. higher performance vs. fewer pauses but would still take more RAM overall.
Using shared pointers for everything is 2x slower at least, which is exactly my point. The C++ new operator is already slower than Javas new. So you pay a performance penalty for careful coding and lose the advantage C++ is supposed to give you.
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.
I respect the fact that you have had different experiences than mine, so I'm not going to argue with your assumptions. I've worked on C++ and Java apps at Google scale and in my experience, C++ builds have been no slower than Java builds (with the right tooling, like I mentioned before). But again, there are a lot of infrastructural factors that can come into play that can influence your experience.
Things like fine-tuning GC just defers the problem instead of solving it. Furthermore, C++ being a compiled language, it does in fact run faster than bytecode in production. Again, it's a tradeoff that you may be willing to make but it's a bit extreme to impugn that the tradeoff doesn't exist.
I'm not assuming there isn't going to be a lapse in judgement at any point. In fact, if you want to play it safe, you can just use shared pointers all the time and avoid all the memory allocation risks that you'd otherwise face. In that regard, C++ is no more unsafe than other languages. As a class designer, however, I find it a lot more expressive to be able to further impose constraints on how other programmers use the interfaces I provide to make it harder to use it incorrectly (oreilly.com/library/view/97-things...).
All of these are design choices and tradeoffs, and they are intrinsically subjective in nature. As a result, I am not going to defend C++ any further on this thread. It's a widely popular language with or without your liking towards it.
Thanks for the discussion though, I did learn some new things and it's always engaging to hear other perspectives!
I wanted to slip in a real world example of a very performant GC. GHC, the most widely used Haskell compiler, uses GC in the compiled runtimes and it's designed around the fact that Haskell works with immutable data.
In result Haskell applications easily match other application performance written in lower level language, at times even exceeding their performance, thanks to optimizations that GHC can apply due to highly expressive Haskell typesystem.
C++ was faster when Google search was developed. It's not as simple today. Performance is a more nuanced debate at this level and benchmarks can mislead both ways. C++ is not faster and neither is Java. There are benchmarks that can go either way.
A JIT inlines virtual methods at runtime, that's something a C++ compiler can't physically do. This is one of those super optimizations that can make a frequently used code path scream since it serves as a basis for further, even deeper optimizations. A well tuned GC can place the peek where you have idle time. C++ will pay a higher price usually on the same thread where things physically happen. To be fair a GC typically needs more RAM to play around with, especially with a JIT. It can tradeoff of more RAM vs. higher performance vs. fewer pauses but would still take more RAM overall.
Using shared pointers for everything is 2x slower at least, which is exactly my point. The C++
newoperator is already slower than Javas new. So you pay a performance penalty for careful coding and lose the advantage C++ is supposed to give you.