9 ms·

I am genuinely curious about the passion of anti C++ commenters - could you comment on your journey towards your current antipathy towards C++? Did you use it a

by dman 8y ago

I am genuinely curious about the passion of anti C++ commenters - could you comment on your journey towards your current antipathy towards C++? Did you use it and get burnt? What did you use it for? What were the short comings? How long did you use it for? When did you use it (ie which C++ standard version)? This is directed not just at the above commenter, but I invite replies from anyone who takes the effort to comment passionately against C++. Perhaps if we can understand some commonalities in peoples grievances, we could go back and address them.

Rusky 8y ago
I don't think I tend to be a passionate anti C++ commenter, though I agree with the sentiment. I've used C++ for around a decade, both professionally and as a hobby, in various domains. I use it because I either need (or merely want, in many cases) the control over the resulting end product that it provides. The grievances are well known, and most are being addressed in some form, so asking random commenters isn't going to change anything. But for what it's worth: it just feels like the language is a lost cause. Everything is so irredeemably hard (without breaking back-compat)- from syntax/name resolution/template expansion, and the accompanying problems with error messages and tooling; to build systems and dependency management, and the impossible task of ever getting anything standard there; to memory+thread safety, where every solution is a partial bandaid and there's no light at the end of the tunnel. It's a big, important, widely-used language. It's just not pleasant to work with- and while that can and will improve, it will always be tied to its rather painful legacy.
- codr4 8y ago
  Second most of that. I used to be really passionate about C++ back in the days, but it's just too damn complex. Yes, some new features really help; if I could bring one to a desert island it would be lambdas. Tuning C++ these days is mostly trial and error for me, there are so many gotchas to keep in mind that it's more or less impossible to juggle it all mentally. From my experience there comes a point where the required effort tips the scales towards more convenient languages for most projects. But by the time you realize you're usually up to your neck in template goo that no one wants to translate.
- vvanders 8y ago
  Yeah, +1 to all of that. I spent maybe ~15 years writing C++ over hobby + career timespan. Was a huge proponent of the language but spent the last 2-3 years over in Java land while doing all my greenfield work in Rust. Came back to another lower level project written in C++/0x14 lately and it's a bit of a shock how my things I 'forgot' even on a modern codebase. Things like implicit constructor conversions, the fact that the type inference is pretty weak still(why can't I just construct unique_ptr w/out the type when I pass it direct[1]). Headers and package management is a total mess. At this point unless I've got a hard constraint(like QNX or other yet supported platforms) I'm going to reach for Rust just about every time. [1] Yes I know make_unique() is a thing but it's a C++/0x17 and just patches one part of type inference issues.
  - berti 8y ago
    make_unique and friends are C++14 ;) https://en.cppreference.com/w/cpp/memory/unique_ptr/make_unique https://en.cppreference.com/w/cpp/memory/unique_ptr/make_uni...
- dnautics 8y ago
  I feel the same way about the the "lost cause" (though I never programmed C++ professionally, I did for science fair projects, and played around, a lot, with the BeOS API back in the day - enough to get RSI): Even JavaScript which kind of felt like a lost cause to me about three years ago has redeemed itself - I was shown a "way to code JavaScript" which exclusively uses ECMA6, keeps very little if no state, and basically everything is a `const fn (...) => {}`. A breath of fresh air in its simplicity and safety. C++ doesn't seem to want to converge to this sort of thing, even as usable subset of the language. I would say the best quality of C++ is that you can be reasonably certain of what the program is doing at the machine language level (though obviously C is better) but this is going to be overtaken by languages like rust, which have more sophisticated type system and unlike VM languages (which definitely have their place) leave safety considerations in the compiler.
- flohofwoe 8y ago
  Same here. Been writing C++ since around 1998, was somewhat excited about C++11 (which brought a few good things, like lambdas, and ... uhm...). Since then I have the impression that C++ and I are moving into different directions. Since last year I started writing C code again and enjoy it very much, surprisingly I haven't missed C++ at all since then. That's when I realized that all I want/need is a "slightly better C" (Go is pretty close but already too high level, in the sense that there's too much under-the-hood-magic happening).
  - merlincorey 8y ago
    > excited about C++11 (which brought a few good things, like lambdas, and ... uhm...) The auto specifier[0] is frankly the most ergonomic and simple thing which I wish I could have in, say, C. [0] https://en.cppreference.com/w/cpp/language/auto https://en.cppreference.com/w/cpp/language/auto :: auto specifier (since C++11)
  - xyzzyz 8y ago
    The biggest thing C++11 brought in my opinion is standardizing scoped_ptr. Now there is absolutely no excuse for typing "new" or "delete" in new code (except of some very limited circumstances).
  - phao 8y ago
    Yep... The "slightly better C" seems pretty universal as far as I've seen. A lot of people just want that it seems. It's not clear what that would look like though. It's a shame. Have you seen Terra? http://terralang.org/ http://terralang.org/
scottlamb 8y ago
> I am genuinely curious about the passion of anti C++ commenters - could you comment on your journey towards your current antipathy towards C++? Did you use it and get burnt? What did you use it for? What were the short comings? How long did you use it for? When did you use it (ie which C++ standard version)? I don't usually write negative comments about C++ but I sure sympathize with them. I write C++ at my day job (and have for years). My team's codebase is in its teenage years. It's code-reviewed and has decent test coverage, but in many cases the author doesn't know C++ as well as the reviewer, and the reviewer is rushed / trying to not be a huge bottleneck, so stuff slips through. New code gets written to mostly C++11 standards (soon, mostly C++17) and the newest company practices. Old code...still exists...and the new code still has to use it. We've modernized some pieces but not as much as we'd like. Company-wide people do a pretty good job of modernizing a lot of the libraries we use, but my team hasn't kept up as well for various reasons. I hate memory errors. They're super hard to track down. I've spent significant time doing so. Thank god for ASAN and TSAN at least. I also don't like crashes in general; my service has to be quite reliable (some operations are critical to big parts of the company and have a 99.9995% success within a certain deadline). And fast, so I can't just rewrite it in Java or Go. A few examples of the sort of foot-guns C++ has: * Data races: no equivalent of Rust's Send+Sync auto traits. * string_view/reference/pointer outliving their backing memory: no lifetime annotations. Even the new proposal for them is very incomplete. * std::optional and equivalents dereferenced incorrectly: no pattern-matching syntax, the decision for the most obvious way to deference (operator*) to be undefined behavior instead of a crash. I wish the whole thing were written in Rust. Then the parts I have to pay super close attention to would all say "unsafe" in them. That covers memory safety (including data races). I'd also know to pay pretty close attention to "expect" and "unwrap", which cover most (not all) panics. Of course, more mundane logic errors can exist in any language, but freedom from those problems would be a huge relief.
- Jabbles 8y ago
  In the >12 years your code has been around, Moore's law suggests that it would have got 2^8 = 256 times faster. Even though that law has slowed, there is significantly more processing power available now than when you started. Are you sure the requirements for your service being "fast" are as critical as you think?
dman 8y ago
Cannot edit my comment anymore, so am putting this here - wanted to thank everyone who took the time to reply. Signal to noise ratio in the comments was fairly high.
userbinator 8y ago
The complexity is just one part of the problem; the constant "fashion" churn --- largely community-driven --- is the other. It's really irritating to see so many changes in the language (and the horde of evangelists seemingly blindly pushing these changes and saying they're unconditionally better, which just smells like snake oil...) and the forcefulness that everyone should continually convert existing --- perfectly working --- code to whatever the current fashion is, when ideally the language should remain static, because I don't think a majority of its users have understood or can make use of most of the features of C++03 or even C++98 yet. Having worked with C++ for over a decade, I much prefer C. C++ certainly has its useful features, but when I use C I find that I don't miss them much; and sometimes, especially when debugging, the "implicitness" of various things like automatic constructor/destructor calls are better made explicit. As a rebuttal to the title of this video: "Hidden complexity is NOT simplicity."
- 01100011 8y ago
  I think one of the issues with C++ is that there seems to be this clique of insanely smart people who are focused mainly on the language itself. They're experts in the complexity they've created and they have nothing to do but study that complexity and evangelize it. They're not really considering the audience of mediocre developers whose minds are mostly concerned with problems that need solutions and not language minutiae. A language and libraries are means to an end, not ends unto themselves. Us normies don't always have the luxury of keeping up to date with language changes - we're busy trying to get work done and ship products. There are hidden costs to technology choices. I work with a smart guy(also a C++ zealot) who loves CMake and constantly evangelizes it. CMake seems great but the problem is that it's yet another language/system which people need to learn to be productive in our environment. GNU Make has its problems, but I can also scoop up a dev off the street and there's a 90% chance they've had experience with GNU Make and can immediately understand what's going on. Now I'm not saying CMake sucks, it's got a lot of great features, but by using it you gave up something without possibly even knowing that you did. Simplicity is a feature. Banality is a feature. Unless you're getting something good in return, don't sacrifice them.
  - 8y ago
stiglitz 8y ago
I can choose C or C++ in my workplace. I prefer primitive rather than clever (i.e. pompous) solutions to problems and therefore choose C. I also do not want to spend a significant portion of my time in the hallway discussing language features, as I hear many C++-choosers doing outside my office most weeks. From this perspective, I could only be made happy with C++ if features were removed from it. I admit that I’ve hardly given the language a chance, but that is partly because I know I’ll make solutions even more pompous than the ones I’ve seen. I don’t think humans can help it.
ndh2 8y ago
Some more interesting comments here: https://www.reddit.com/r/cpp/comments/9jwdpf/journeys_towards_c_antipathy/ https://www.reddit.com/r/cpp/comments/9jwdpf/journeys_toward...

by dman 8y ago

Rusky 8y ago

I don't think I tend to be a passionate anti C++ commenter, though I agree with the sentiment. I've used C++ for around a decade, both professionally and as a hobby, in various domains. I use it because I either need (or merely want, in many cases) the control over the resulting end product that it provides. The grievances are well known, and most are being addressed in some form, so asking random commenters isn't going to change anything. But for what it's worth: it just feels like the language is a lost cause. Everything is so irredeemably hard (without breaking back-compat)- from syntax/name resolution/template expansion, and the accompanying problems with error messages and tooling; to build systems and dependency management, and the impossible task of ever getting anything standard there; to memory+thread safety, where every solution is a partial bandaid and there's no light at the end of the tunnel. It's a big, important, widely-used language. It's just not pleasant to work with- and while that can and will improve, it will always be tied to its rather painful legacy.

codr4 8y ago
Second most of that. I used to be really passionate about C++ back in the days, but it's just too damn complex. Yes, some new features really help; if I could bring one to a desert island it would be lambdas. Tuning C++ these days is mostly trial and error for me, there are so many gotchas to keep in mind that it's more or less impossible to juggle it all mentally. From my experience there comes a point where the required effort tips the scales towards more convenient languages for most projects. But by the time you realize you're usually up to your neck in template goo that no one wants to translate.
vvanders 8y ago
Yeah, +1 to all of that. I spent maybe ~15 years writing C++ over hobby + career timespan. Was a huge proponent of the language but spent the last 2-3 years over in Java land while doing all my greenfield work in Rust. Came back to another lower level project written in C++/0x14 lately and it's a bit of a shock how my things I 'forgot' even on a modern codebase. Things like implicit constructor conversions, the fact that the type inference is pretty weak still(why can't I just construct unique_ptr w/out the type when I pass it direct[1]). Headers and package management is a total mess. At this point unless I've got a hard constraint(like QNX or other yet supported platforms) I'm going to reach for Rust just about every time. [1] Yes I know make_unique() is a thing but it's a C++/0x17 and just patches one part of type inference issues.
- berti 8y ago
  make_unique and friends are C++14 ;) https://en.cppreference.com/w/cpp/memory/unique_ptr/make_unique https://en.cppreference.com/w/cpp/memory/unique_ptr/make_uni...
dnautics 8y ago
I feel the same way about the the "lost cause" (though I never programmed C++ professionally, I did for science fair projects, and played around, a lot, with the BeOS API back in the day - enough to get RSI): Even JavaScript which kind of felt like a lost cause to me about three years ago has redeemed itself - I was shown a "way to code JavaScript" which exclusively uses ECMA6, keeps very little if no state, and basically everything is a `const fn (...) => {}`. A breath of fresh air in its simplicity and safety. C++ doesn't seem to want to converge to this sort of thing, even as usable subset of the language. I would say the best quality of C++ is that you can be reasonably certain of what the program is doing at the machine language level (though obviously C is better) but this is going to be overtaken by languages like rust, which have more sophisticated type system and unlike VM languages (which definitely have their place) leave safety considerations in the compiler.
flohofwoe 8y ago
Same here. Been writing C++ since around 1998, was somewhat excited about C++11 (which brought a few good things, like lambdas, and ... uhm...). Since then I have the impression that C++ and I are moving into different directions. Since last year I started writing C code again and enjoy it very much, surprisingly I haven't missed C++ at all since then. That's when I realized that all I want/need is a "slightly better C" (Go is pretty close but already too high level, in the sense that there's too much under-the-hood-magic happening).
- merlincorey 8y ago
  > excited about C++11 (which brought a few good things, like lambdas, and ... uhm...) The auto specifier[0] is frankly the most ergonomic and simple thing which I wish I could have in, say, C. [0] https://en.cppreference.com/w/cpp/language/auto https://en.cppreference.com/w/cpp/language/auto :: auto specifier (since C++11)
- xyzzyz 8y ago
  The biggest thing C++11 brought in my opinion is standardizing scoped_ptr. Now there is absolutely no excuse for typing "new" or "delete" in new code (except of some very limited circumstances).
- phao 8y ago
  Yep... The "slightly better C" seems pretty universal as far as I've seen. A lot of people just want that it seems. It's not clear what that would look like though. It's a shame. Have you seen Terra? http://terralang.org/ http://terralang.org/

scottlamb 8y ago

> I am genuinely curious about the passion of anti C++ commenters - could you comment on your journey towards your current antipathy towards C++? Did you use it and get burnt? What did you use it for? What were the short comings? How long did you use it for? When did you use it (ie which C++ standard version)? I don't usually write negative comments about C++ but I sure sympathize with them. I write C++ at my day job (and have for years). My team's codebase is in its teenage years. It's code-reviewed and has decent test coverage, but in many cases the author doesn't know C++ as well as the reviewer, and the reviewer is rushed / trying to not be a huge bottleneck, so stuff slips through. New code gets written to mostly C++11 standards (soon, mostly C++17) and the newest company practices. Old code...still exists...and the new code still has to use it. We've modernized some pieces but not as much as we'd like. Company-wide people do a pretty good job of modernizing a lot of the libraries we use, but my team hasn't kept up as well for various reasons. I hate memory errors. They're super hard to track down. I've spent significant time doing so. Thank god for ASAN and TSAN at least. I also don't like crashes in general; my service has to be quite reliable (some operations are critical to big parts of the company and have a 99.9995% success within a certain deadline). And fast, so I can't just rewrite it in Java or Go. A few examples of the sort of foot-guns C++ has: * Data races: no equivalent of Rust's Send+Sync auto traits. * string_view/reference/pointer outliving their backing memory: no lifetime annotations. Even the new proposal for them is very incomplete. * std::optional and equivalents dereferenced incorrectly: no pattern-matching syntax, the decision for the most obvious way to deference (operator*) to be undefined behavior instead of a crash. I wish the whole thing were written in Rust. Then the parts I have to pay super close attention to would all say "unsafe" in them. That covers memory safety (including data races). I'd also know to pay pretty close attention to "expect" and "unwrap", which cover most (not all) panics. Of course, more mundane logic errors can exist in any language, but freedom from those problems would be a huge relief.

Jabbles 8y ago
In the >12 years your code has been around, Moore's law suggests that it would have got 2^8 = 256 times faster. Even though that law has slowed, there is significantly more processing power available now than when you started. Are you sure the requirements for your service being "fast" are as critical as you think?

dman 8y ago

Cannot edit my comment anymore, so am putting this here - wanted to thank everyone who took the time to reply. Signal to noise ratio in the comments was fairly high.

userbinator 8y ago

The complexity is just one part of the problem; the constant "fashion" churn --- largely community-driven --- is the other. It's really irritating to see so many changes in the language (and the horde of evangelists seemingly blindly pushing these changes and saying they're unconditionally better, which just smells like snake oil...) and the forcefulness that everyone should continually convert existing --- perfectly working --- code to whatever the current fashion is, when ideally the language should remain static, because I don't think a majority of its users have understood or can make use of most of the features of C++03 or even C++98 yet. Having worked with C++ for over a decade, I much prefer C. C++ certainly has its useful features, but when I use C I find that I don't miss them much; and sometimes, especially when debugging, the "implicitness" of various things like automatic constructor/destructor calls are better made explicit. As a rebuttal to the title of this video: "Hidden complexity is NOT simplicity."

01100011 8y ago
I think one of the issues with C++ is that there seems to be this clique of insanely smart people who are focused mainly on the language itself. They're experts in the complexity they've created and they have nothing to do but study that complexity and evangelize it. They're not really considering the audience of mediocre developers whose minds are mostly concerned with problems that need solutions and not language minutiae. A language and libraries are means to an end, not ends unto themselves. Us normies don't always have the luxury of keeping up to date with language changes - we're busy trying to get work done and ship products. There are hidden costs to technology choices. I work with a smart guy(also a C++ zealot) who loves CMake and constantly evangelizes it. CMake seems great but the problem is that it's yet another language/system which people need to learn to be productive in our environment. GNU Make has its problems, but I can also scoop up a dev off the street and there's a 90% chance they've had experience with GNU Make and can immediately understand what's going on. Now I'm not saying CMake sucks, it's got a lot of great features, but by using it you gave up something without possibly even knowing that you did. Simplicity is a feature. Banality is a feature. Unless you're getting something good in return, don't sacrifice them.
- 8y ago

stiglitz 8y ago

I can choose C or C++ in my workplace. I prefer primitive rather than clever (i.e. pompous) solutions to problems and therefore choose C. I also do not want to spend a significant portion of my time in the hallway discussing language features, as I hear many C++-choosers doing outside my office most weeks. From this perspective, I could only be made happy with C++ if features were removed from it. I admit that I’ve hardly given the language a chance, but that is partly because I know I’ll make solutions even more pompous than the ones I’ve seen. I don’t think humans can help it.

ndh2 8y ago

Some more interesting comments here: https://www.reddit.com/r/cpp/comments/9jwdpf/journeys_towards_c_antipathy/ https://www.reddit.com/r/cpp/comments/9jwdpf/journeys_toward...