Fast is subjective but inherently C++ compilation is MUCH slower than most languages. There's just a lot more to evaluate and unpack. This is an inherent limitation. It might be OK for smaller projects but even at 100k LoC this is very noticeable.
I pretty much disagree with most of your points but this one bothers me the most:
C++ is only unsafe and unpredictable if, like I said, you don't know what you're doing. Languages like Java take thinking away from you by putting all objects on the heap and only maintaining pointers. If you know what you're doing, you might not want that in some cases. This causes issues with Garbage Collection being extremely slow.
Two things bother me here:
Thinking we're smart - that's a dangerous path to walk. All you need is one lapse of judgement, one botched code review, one weak link and boom. I worked with a lot of very smart people who wrote dumb code a few times. The assumption that we're smart or that we "know what we are doing" is a flawed assumption. You're also making that assumption of every team member, every dependency and library you use and every update you get...
GC is slow - This is a common falsehood that derives from bad implementations and configurations.
GC allows super fast allocators in Java. In fact it beats some of the fastest C allocators. The cool thing about GC is that de-allocation can happen asynchronously on a separate thread during CPU idle time. That's very efficient...
The points where this becomes a problem are:
HUGE heap sizes
Low memory mode where GC thrashes
Newer GCs deal well with both of those cases through multiple strategies that include concurrency, generational division etc. The thing is that memory management becomes a "deployment decision" and not something the programmer should decide during development. You can profile the performance of your application in runtime and fine tune the GC/memory to produce predictable high throughput results.
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.
Fast is subjective but inherently C++ compilation is MUCH slower than most languages. There's just a lot more to evaluate and unpack. This is an inherent limitation. It might be OK for smaller projects but even at 100k LoC this is very noticeable.
I pretty much disagree with most of your points but this one bothers me the most:
Two things bother me here:
Thinking we're smart - that's a dangerous path to walk. All you need is one lapse of judgement, one botched code review, one weak link and boom. I worked with a lot of very smart people who wrote dumb code a few times. The assumption that we're smart or that we "know what we are doing" is a flawed assumption. You're also making that assumption of every team member, every dependency and library you use and every update you get...
GC is slow - This is a common falsehood that derives from bad implementations and configurations.
GC allows super fast allocators in Java. In fact it beats some of the fastest C allocators. The cool thing about GC is that de-allocation can happen asynchronously on a separate thread during CPU idle time. That's very efficient...
The points where this becomes a problem are:
Newer GCs deal well with both of those cases through multiple strategies that include concurrency, generational division etc. The thing is that memory management becomes a "deployment decision" and not something the programmer should decide during development. You can profile the performance of your application in runtime and fine tune the GC/memory to produce predictable high throughput results.
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.