C++ is unsafe. Rust is better while still giving low level control and performance. Not to mention VM languages like Java...
C++ isn't faster than Java, Go, Rust, C etc.
C++ libraries aren't even remotely close to the stuff you get with Java, Python etc. Even basic stuff is pretty hard to do. Hell, I had a job to fix an XSLT processor in C++, it would have been easier to just rewrite that whole thing in Java in a couple of hours.
C++ tooling isn't nearly at the level of Java. Neither in terms of debuggers or in terms of static analysis, refactoring etc. The closest thing is visual studio which is a proprietary windows app. Even jetrains tools lack when it comes to C++, it's just too hard even for the tools.
C++ still isn't portable in 2021. Yes you can code defensively but it's still bad and you end up in Macro hell with cmake configuration from hell.
C++ takes ages to compile because of features such as templates... When it fails the compiler output is downright unreadable.
C++ has a lot of hidden features/behaviors that are often compiler specific. It has nuances that are easily triggered and fail in odd ways.
C is much simpler, doesn't suffer from template bloat and compiles faster. It's more portable (albeit also with its own problems).
I liked C++ a lot in my youth. As I grew older and had to maintain code on multiple projects the pain of C++ became very apparent and I learned to hate it deeply. When I last needed to write a JVM I used pure C and it was remarkably easy. C++ is just unpleasant to work with.
C is nice and all but we should stop using C and start looking into a safer lang. The unsafe properties of C is not gonna cut it in the next years where safe code is going to be important. Code is going to run even more on cars and other mission critical platforms. Maybe Rust. dont know.
I very much agree. When I built ParparVM I picked C as the underlying language. Rust wasn't a realistic option back then. Had I done that today I would totally have picked it.
Mr Almond, you said that C++ is unsafe but you didn't give any clues. Then you said Rust is better (did you mean safer?) but you didn't mention in which sense. And you didn't give any clues again. Then you said C++ isn't faster, but you didn't mention any benchmarks. I stopped reading further because from what I read I conclude you are biased and opinionated against C++.
You can also do a slight bit of self research to learn about these things on your own e.g. this article is a bit out of date (and has problematic choices) but shows off some of the complexities of decreeing C++ as faster: en.wikipedia.org/wiki/Java_perform...
I've been a C++ developer since the early 90s. Hell yes, I'm biased against C++. I've also built JVMs (mostly in C but also in C++) so I'm pretty familiar with the performance nuances and benchmarks. Feel free to disregard my experience and go back to your bubble.
I was going to rebut your counterpoints since I'm a C++ fanboy, but I think they're all true. (I've been programming in C++ for 33 years now. My current project is an extremely large, extremely old C++ project)
Some of the counterpoints are a bit a "matter of degree", most of others are "yep, no doubt about it".
C++ tooling will never be as good as Java or C# tooling. Lack of reflection, lack of introspection, lack of AST manipulation, and the preprocessor are all huge barriers to having powerful reliable and robust tooling. The refactoring tools for Java and C# are killer features in IDEs like Visual Studio with Resharper or CodeRush, or Eclipse, or the wonderful IDEs from the folks at JetBrains. That's the counterpoint that stings the most.
Ultimately you're entitled to your opinion but there are some things I disagree with.
Like I mentioned in my article, tools like Bazel make builds significantly fast. I personally don't prefer using CMake. There are static analysis tools like Kythe that also work beautifully with C++.
Like it or not, virtualization has a performance cost and a simple Google search would confirm that this makes C++ faster than Java at least. For many use cases, the advantages may outweigh the costs and that's fair. I personally love the Erlang VM and all the guarantees that it provides and I'd much rather use Elixir/Phoenix than C++/OpenMP to build real time distributed apps.
If you like the simplicity of C, there's nothing wrong with that. It just comes with its own memory management nightmares when you need to work with the heap. C++ simplifies that a lot without losing performance advantages of C. There are other things like function pointers which are wonky in C but much better in C++. Also, for larger projects, OOP makes it much easier to design systems IMO, but that is a personal preference.
Depending on how you define portability, C++ actually can run on any system and if you don't use very low level features (which you can't use in Java/Python anyway without C/C++ shared libs), it really does compile and run seamlessly.
CLion and Visual Studio suffice all my general needs when writing C++, but I have friends who use VSCode with C++ extensions as well and that works well for them.
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.
Again, in the end it comes down to preference. Whether or not you find a language beautiful and elegant is subjective and while I've tried my best to convince you with this article that it's not as unpleasant as most people remember it to be, I don't mean to belittle any other languages. They're all awesome and I use several of them all the time.
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.
Counterpoint: there are way better languages.
C++ is unsafe. Rust is better while still giving low level control and performance. Not to mention VM languages like Java...
C++ isn't faster than Java, Go, Rust, C etc.
C++ libraries aren't even remotely close to the stuff you get with Java, Python etc. Even basic stuff is pretty hard to do. Hell, I had a job to fix an XSLT processor in C++, it would have been easier to just rewrite that whole thing in Java in a couple of hours.
C++ tooling isn't nearly at the level of Java. Neither in terms of debuggers or in terms of static analysis, refactoring etc. The closest thing is visual studio which is a proprietary windows app. Even jetrains tools lack when it comes to C++, it's just too hard even for the tools.
C++ still isn't portable in 2021. Yes you can code defensively but it's still bad and you end up in Macro hell with cmake configuration from hell.
C++ takes ages to compile because of features such as templates... When it fails the compiler output is downright unreadable.
C++ has a lot of hidden features/behaviors that are often compiler specific. It has nuances that are easily triggered and fail in odd ways.
C is much simpler, doesn't suffer from template bloat and compiles faster. It's more portable (albeit also with its own problems).
I liked C++ a lot in my youth. As I grew older and had to maintain code on multiple projects the pain of C++ became very apparent and I learned to hate it deeply. When I last needed to write a JVM I used pure C and it was remarkably easy. C++ is just unpleasant to work with.
C is nice and all but we should stop using C and start looking into a safer lang. The unsafe properties of C is not gonna cut it in the next years where safe code is going to be important. Code is going to run even more on cars and other mission critical platforms. Maybe Rust. dont know.
I very much agree. When I built ParparVM I picked C as the underlying language. Rust wasn't a realistic option back then. Had I done that today I would totally have picked it.
Mr Almond, you said that C++ is unsafe but you didn't give any clues. Then you said Rust is better (did you mean safer?) but you didn't mention in which sense. And you didn't give any clues again. Then you said C++ isn't faster, but you didn't mention any benchmarks. I stopped reading further because from what I read I conclude you are biased and opinionated against C++.
These are common terms and easily checked. I suggest reading this: en.wikipedia.org/wiki/Rust_(progra...
You can also do a slight bit of self research to learn about these things on your own e.g. this article is a bit out of date (and has problematic choices) but shows off some of the complexities of decreeing C++ as faster: en.wikipedia.org/wiki/Java_perform...
I've been a C++ developer since the early 90s. Hell yes, I'm biased against C++. I've also built JVMs (mostly in C but also in C++) so I'm pretty familiar with the performance nuances and benchmarks. Feel free to disregard my experience and go back to your bubble.
I was going to rebut your counterpoints since I'm a C++ fanboy, but I think they're all true. (I've been programming in C++ for 33 years now. My current project is an extremely large, extremely old C++ project)
Some of the counterpoints are a bit a "matter of degree", most of others are "yep, no doubt about it".
C++ tooling will never be as good as Java or C# tooling. Lack of reflection, lack of introspection, lack of AST manipulation, and the preprocessor are all huge barriers to having powerful reliable and robust tooling. The refactoring tools for Java and C# are killer features in IDEs like Visual Studio with Resharper or CodeRush, or Eclipse, or the wonderful IDEs from the folks at JetBrains. That's the counterpoint that stings the most.
Ultimately you're entitled to your opinion but there are some things I disagree with.
Like I mentioned in my article, tools like Bazel make builds significantly fast. I personally don't prefer using CMake. There are static analysis tools like Kythe that also work beautifully with C++.
Like it or not, virtualization has a performance cost and a simple Google search would confirm that this makes C++ faster than Java at least. For many use cases, the advantages may outweigh the costs and that's fair. I personally love the Erlang VM and all the guarantees that it provides and I'd much rather use Elixir/Phoenix than C++/OpenMP to build real time distributed apps.
If you like the simplicity of C, there's nothing wrong with that. It just comes with its own memory management nightmares when you need to work with the heap. C++ simplifies that a lot without losing performance advantages of C. There are other things like function pointers which are wonky in C but much better in C++. Also, for larger projects, OOP makes it much easier to design systems IMO, but that is a personal preference.
Depending on how you define portability, C++ actually can run on any system and if you don't use very low level features (which you can't use in Java/Python anyway without C/C++ shared libs), it really does compile and run seamlessly.
CLion and Visual Studio suffice all my general needs when writing C++, but I have friends who use VSCode with C++ extensions as well and that works well for them.
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.
Again, in the end it comes down to preference. Whether or not you find a language beautiful and elegant is subjective and while I've tried my best to convince you with this article that it's not as unpleasant as most people remember it to be, I don't mean to belittle any other languages. They're all awesome and I use several of them all the time.
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.