7 ms·

Man, the negative sentiment on this site towards C++ is pretty alien to me. C++ is (I'm guessing) currently holding up an order of magnitude more applications

by net_ 4y ago

Man, the negative sentiment on this site towards C++ is pretty alien to me. C++ is (I'm guessing) currently holding up an order of magnitude more applications than whatever you think is better than it. Clearly it has upsides, so it's baffling to me when people greet attempts to reduce the downsides with either "This doesn't make sense, just scrap it for something else" or endless nitpicks about the approach chosen. A smart guy has decided to put his time towards improving a hugely influential language. That seems like an uncontroversial positive to me, and I welcome any useful results.

otabdeveloper4 4y ago
> programming is hard, let's go (language) shopping instead
guitarbill 4y ago
It doesn't feel much different to any other language that people have been burned by (e.g. Javascript). I have some bad C++ experienced, and I know enough programmers I respect who stick to C over C++. Of course it's difficult to equate that kind of advice/feedback to negative comments on HN. But often, there's some kernel of truth there. So while there's some merit to C++, the criticism can equally be valid. And keeping the underlying complexity of C++ (similar to how Carbon will) might not meaningfully simplify development).
- einpoklum 4y ago
  > I have some bad C++ experienced, and I know enough programmers I respect who stick to C over C++. Do you know such people who work on large software systems, as opposed to, say, micro-controller firmware, or kernel drivers and such? (Asking as a person who maintains an important(ish) C library for embedded coders: https://github.com/eyalroz/printf https://github.com/eyalroz/printf)
  - Galanwe 4y ago
    On the top of my head, for large open source C codebases that are not system/kernel/controller I guess Python, Ruby and Redis would be good examples. I do myself fall in the category of people sticking to C over C++. I used to love C++ back until c++03, then completely hated the whole "new generation c++" orientation that started with c++11 and pretty much decided to not touch c++ anymore.
    - jcelerier 4y ago
      I think that "large" really needs to be defined here. CPython is 350kloc of C. I have seen C++ codebases with more source files than there are lines of code in that. Just the "base" module of Qt is ~4million loc
  - 1024core 4y ago
    > Do you know such people who work on large software systems, as opposed to, say, micro-controller firmware, or kernel drivers and such? Redis is written entirely in C.
    - summerlight 4y ago
      I don't think that Redis qualifies as a large software system in the modern standard. In fact, it's popular because it's simple, small and understandable compared to its competitors which comprises of many millions of lines of code.
    - jrockway 4y ago
      I really don't think Redis is a large software system. Things like Firefox, Chrome, AAA games, etc. are what I'd call large C++ systems.
    - einpoklum 4y ago
      Redis is ~200K lines of C code, so it's relevant project-size-wise, but - redis was started in C, right? It's not like developers now have the option to "go C++" without a company-wide decision. Still, if could quote Redis developers making the GP's claim, that would count.
  - mek6800d2 4y ago
    I used to work for a company whose product was a fairly large satellite control center software system (and we could supply hardware if needed), written in C++. It's used for a lot of commercial fleets. For example, back in the 2000s, when I worked on it, it was used for CDRADIO/Sirius's fleet. (I don't know if it's still used for SiriusXM's Sirius satellites, if any.) I liked C++ in some ways, but as a whole, I think, C++ didn't reduce -- and may have increased -- the complexity of our software compared to the complexity of an equivalent C implementation. (I'm talking about the complexity of the software itself, not the complexities of the tasks it was doing.) The distribution of the complexity in the code would just have been different between the two implementations. IMHO. So I mostly stick with C or other non-C++ languages now. Of course, C++ has expanded and changed greatly since then.
    - ncmncm 4y ago
      You would be very pleasantly surprised at how programming in C+ is, today, vs. pre-C++11. With C++20, the language has got even nicer to use.
      - throwaway894345 4y ago
        I remember really enjoying C++ circa 2012, but I really hated scripting my own build tooling via CMake or manually wrangling dependencies. This was the stuff that pushed me out of C++. Fortunately, Go had just hit 1.0 and it fixed many of the problems out of the gate, and I didn’t really need the performance that C++ offered.
        ncmncm 4y ago
        Even CMake has got less annoying.
        throwaway894345 4y ago
        It had nowhere to go but up! (: Jokes aside, I’m glad to hear it.
  - guitarbill 4y ago
    Some software for storage products is C. I imagine other conservative industries could be similar. But I have also heard that although the senior devs would prefer to stick to C for technical reasons, they have started to use/embrace C++ for hiring reasons (since many grads are taught C++). So I wouldn't be surprised if finding "pure" C codebases/ones without C++ is getting harder. The eco-system around C++ (e.g. test frameworks) certainly seemed healthier. It's been a few years though, so I might not have a good picture any more.
bowsamic 4y ago
I agree, and I don't think it's as hard or complex as people make it out to be
zozbot234 4y ago
> C++ is (I'm guessing) currently holding up an order of magnitude more applications than whatever you think is better than it. So what. No one's going to rewrite all of those million lines of code in New C++, or whatever they call this incompatible syntax. It's just a distraction from more relevant efforts.
- pavlov 4y ago
  New code can be written in the new syntax, with full access to existing libraries. I could easily see a company like Meta adopting this. They have both a huge amount of C++ code as well as actively developed guidelines and internal libraries that make use of cutting-edge features.
- pelario 4y ago
  From the link: "I'm sharing this work because I hope to start a conversation about what could be possible within C++’s own evolution to rejuvenate C++, now that we have C++20 and soon C++23 to build upon." Clearly this is relevant for c++ itself (coming from Sutter), so I'd say it's quite unfair/misguided to call it "just a distraction from more relevant efforts."
- the-smug-one 4y ago
  If you've got 10^6 LoC of a product that will be developed and maintained for 10+ more years then you can slowly replace it with this.
- zbird 4y ago
  Of course they will. What they are less likely to do is to rewrite it in a completely different language (e.g. Rust.) C++ became popular in the first place because it could easily go along with C. No need to rewrite in bulk.
  - stormbrew 4y ago
    The thing is that C is still the lingua franca abi, so there's still no need to rewrite in bulk, you can still just use the same C libraries in another language, and rust is particularly well suited to doing that in roughly the same ways C++ is. What's getting harder and harder to see now is why, if you need to write new or rewrite now, you'd choose C++ over rust. In the long run that's a recipe for only the most gnarly old codebases being written in c++ and no one wanting to touch them.
benj111 4y ago
Familiarity breeds contempt? I'm sure many would dislike rust if they were forced to use it. Same with python, etc, etc, etc. I'm not saying the criticisms are wrong per se, but the reason we have so many languages is probably because there's no 'right' language.
uoaei 4y ago
zhxshen 4y ago
The text-include compilation model is broken, larger projects pay dearly for this, and thanks to C++'s very long history & very long feature list, there is a veritable Babel of feature subsets & compiler opts to choose from. Adding new dialects and features is not an improvement here.
- klodolph 4y ago
  This is what the "modules" feature in C++20 addresses. People are complaining about modules a lot, I think because the spec is a little complicated... but the spec is a little complicated because the problem is a little complicated, and you can't pretend that complexity doesn't exist when you're writing the spec. (There are some other complaints about the modules system. It wasn't going to please everyone.) New dialects and features were getting added to JS all the time, but what happens is people writing JS libraries or tooling would watch how far these features spread in their users' browser compile base, and many of these various features would never even make it into popular JS runtimes, while others are everywhere now. I think it's a reasonable model for development--lots of people trying to improve things, the community slowly sifts it out, and the standards are the most conservative of all.
  - zhxshen 4y ago
    > because the spec is a little complicated Patching over the old work--hopefully without breaking anything--always is. I'm just stating that much of the hostility toward C++ comes from the fact that we have so many superior options to choose from now--options which profited from the lessons C++ learned the hard way, and incorporated them into v1 instead of patching them in as options at v23. And this is not to strikeforce anyone with a "Rewrite it in Rust!", but to suggest that C++ is maybe not the best choice for new work in 2022.
  - forrestthewoods 4y ago
    People complain about modules because they only exist on paper. Not a single compiler supports the standard library as a module. No compiler has full support for modules. Modules are a C++20 feature that isn't usable in real projects in 2022. And there's no signs that modules will be ready anytime soon.
alar44 4y ago
I will probably get some flack for this but it's an effect of the Python generation. When you can pull in some libraries and build some bloated slow as hell code in minutes, no one cares what's under the hood. The tradeoff from performance (easily 1000s of times, I've seen it swapping out simple python libs for c++, specifically changing dicts to linked lists) to ease of slapping things together makes me sad daily.
- lolinder 4y ago
  Why would a trade-off make you sad? For most code that gets written, being able to quickly make something work is far more important than a 1000x increase in performance. Some projects do need performance, and for those no one should choose Python. For all the others, I'm glad Python exists.
  - alar44 4y ago
    Because there's lots of projects out there with absolutely horrible optimization. Doing stupid shit inside of loops etc. It turns into the blind leading the blind and churns out bad code.
pjmlp 4y ago
C++ is a great language, the sub culture that keeps unsafe C patterns alive in the language, not so much. Example, back in the heyday of C++ frameworks bundled with compilers, bounds checking strings and collection arrays were the default. Nowadays you either call at(), have your own bounded checked types, or enable the debug library, but naturally without influence on 3rd party depedencies.
staticassertion 4y ago
> Clearly it has upsides, All that you've indicated is that it's used a lot, which is obviously because it has decades on every other option. Anyway, I love Herb Sutter and I love this work he's doing. Awesome stuff.
throwaway894345 4y ago
“Holding up an order of magnitude more applications … clearly it has upsides”. It’s holding up lots of applications because better languages didn’t exist at the time those projects were started, and it’s rarely feasible to switch languages. Specifically, a lot of people look to Rust to unseat C++ for new applications, but it will take a while for Rust to mature with respect to libraries (e.g., game engines) and mindshare in those industries. But even then, old languages have tons of staying power by virtue of age.
- YZF 4y ago
  I'm not super familiar with Rust, do you have SSE/AVX intrinsics (others?)? Can you write assembly embedded in Rust code? How does rust stack in terms of performance? https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... looks quite decent, but overall Rust is still behind? So if I am in an area where performance (or cost/energy) is king then I'd still pick C++.
  - agersant 4y ago
    > do you have SSE/AVX intrinsics (others?)? Yes. https://docs.rs/simd/latest/simd/ https://docs.rs/simd/latest/simd/ > Can you write assembly embedded in Rust code? Also yes. https://doc.rust-lang.org/reference/inline-assembly.html https://doc.rust-lang.org/reference/inline-assembly.html
  - the_jesus_villa 4y ago
    I don't know the answers to all of your questions, but >Can you write assembly embedded in Rust code? Yes, I've done this several times. It looks like this: https://doc.rust-lang.org/rust-by-example/unsafe/asm.html https://doc.rust-lang.org/rust-by-example/unsafe/asm.html
  - dento 4y ago
    SIMD intrinsics exist, although currently require nightly compiler on non-x86 targets: https://doc.rust-lang.org/1.29.0/core/arch/x86/index.html https://doc.rust-lang.org/1.29.0/core/arch/x86/index.html Inline assembly: https://rust-lang.github.io/rfcs/2873-inline-asm.html https://rust-lang.github.io/rfcs/2873-inline-asm.html Performance is almost identical, even the linked benchmark is quite even.
mattgreenrocks 4y ago
My theory is that the Internet generally hates multi-paradigm languages (Scala!). Key phrase there is “the Internet,” which is a euphemism for “people who write in the comment section.” They aren’t a representative sample, just a vocal one. There are plenty of good reasons to hate on C++, but that’s conflated with a lot of “real hacker” signaling. Most takes on C++ lament that it isn’t C, or is too complex. Rust is a quality replacement for C++, but it doesn’t succeed on either of those counts either. All new code I write is in Rust or Haskell. If I need to do something weird, like with DynamoRIO, C++ it is.
- riffraff 4y ago
  Python and Ruby were considered multiparadigm languages once, and the internet didn't hate them at all. I think "the internet" tends to complain about languages which have accrued complexity over time, and contain parts that are now considered bad but still lurk in the shadows tripping you up. Scala, C++, perl and others seem to fall into this category.
  - throwaway894345 4y ago
    I think the Internet doesn’t like languages that don’t have good, strong opinions that will help you find a successful path. C++ just says “here’s every feature we’ve ever heard of; good luck!” whereas Go has strong opinions about how you should build software and while they might change people, they really do put you on the right track. Rust is closer to Rust, but it has so many features that it still takes some time to figure out the happy path—fortunately, the Rust community makes up for a lot of that with excellent documentation (e.g., the Rust Book) and helpful, friendly forums.
    - mattgreenrocks 4y ago
      Yes, this is what I'm getting at. There's a very real desire for things to just be laid out for you, and much less regard for whether the workflow/tradeoffs associated with that beget quality software in the process. It is hard to not see this as an army of advanced beginners unconsciously trying to avoid doing the work required to level up.
Volker_W 4y ago
> C++ is (I'm guessing) currently holding up an order of magnitude more applications than whatever you think is better than it. You could say the same thing about COBOL. (Not that I think that C++ is as bad as COBOL.)
0x457 4y ago
I think not many people ever got properly introduced to C++. Some probably only saw it during their format education, and it's most likely been taught like C with classes and/or they had to use for stupid things. There are also many forms of C++, there is your "old and regular" C++, game dev C++, there is modern C++, then there is "I only know C, but sure I can write C++" C++. Pulling dependencies is not as simple as `npm i boost`. Communities are small, segmented and not welcoming to newbies. Absolute madness with build tools. I've never worked with CMake myself until last year, and I haven't so frustrated. As for how many applications using C++ that's not really an argument — C++ was literally the only choice for many of them at that time.
- FerociousTimes 4y ago
  I echo the same sentiment here but mainly for C language as If my memory serves me right, I didn't have any encounter with C++. My experience was negative overall and traumatic to some extent and I wouldn't rule out that some who were first exposed to the language in college or even HS share the same aversion and feel scarred and haunted forever by that Blue Ghost.
- spookie 4y ago
  Not really an argument? The C/C++ ecosystem is so well established that even today you don't have a choice in a lot of contexts. If that doesn't show the power of a language, I don't know what can. I don't really think the community is toxic or unwelcoming, more like people are too used to ctrl+c ctrl+v their way out of problems. Nothing against that, I'm the same way, but it really is a matter of taking your time with the language. I've honestly learned to applaud most rust fanatics because of this, at least they are passionate about learning athe language inside/out.
  - throwaway894345 4y ago
    Where is C++ the only choice? Gamedev seems like the closest—as far as I know, most AAA games aren’t using C, but I think maybe many are using C# via Unity (I’m not familiar with the gamedev space)? In the embedded world, C still reigns supreme. Maybe in the world of high frequency trading? But these seem to be fewer and fewer and Rust seems increasingly likely to be a contender in these domains.
ryukoposting 4y ago
C++'s main upside is that it's the least common denominator. Also its runtime is friendly to embedded systems (kind of). I welcome good replacements for C++'s syntax, because it's genuinely terrible.
CamperBob2 4y ago
That's true, but at the same time, modern C++ bears about the same resemblance to the C++ that many (if not most) of us learned years ago, as modern English bears to Middle English. People have been trying to make the language safer and more palatable for multiple decades now, so it seems reasonable to allow Sutter to have a go at it.
cplusplusfellow 4y ago
I’m truly thankful in my life for Sutter doing the work he does to make this language better. He is a giant.
asveikau 4y ago
I came up with the following guess many years ago: There are people who are totally unproductive at C++ and find it scary, mainly because they are not very exposed to it. They assume everybody is as uncomfortable and unproductive with it as they are. Nay, it is impossible for anyone to be productive with it, simply because they aren't. They will attack evidence that somebody has done well with it, because it is some defense of ego for them. There are other complaints about C++ beyond this of course, with validity, and many of them from old timers and people who bitterly complained about it for decades from a place of knowledge and experience. People have been complaining about ugliness of C++ for longer than my own career. However, as more and more people come up in the post-C++-as-fashionable era, I think this above theory is more and more the bulk of the complaints.
hvs 4y ago
C++ is like the English language. Extraordinarily popular, hard to learn, and full of weird cruft. You can write amazing things in it as well as terribly unsafe garbage.
- account42 4y ago
  English is not particularly hard to learn.
MaulingMonkey 4y ago
> Clearly it has upsides, so it's baffling to me when people greet attempts to reduce the downsides with either "This doesn't make sense, just scrap it for something else" or endless nitpicks about the approach chosen. People have been working to reduce the downsides of C++ for decades at this point, and the results are incredibly lackluster, and frequently only work in trivial toy examples - if even then. Every now and then I try out the latest and greatest I can find in terms of dangling pointer prevention, and find myself confused as to if I've even enabled the proper checks, when even my trivial toy examples fail to trigger said checks, only to be horrified when I in fact have enabled said checks and gained nothing. I, too, welcome any useful results. The problem is: I don't actually find the results useful. I get told garbage like "C++ is safe now!" by people who apparently don't know any better, for things underperforming existing static analysis tools from over a decade ago. It's a distraction, a false promise, and a waste of my time - which could be better spent reviewing C++ code, improving existing static analysis coverage, or going full ham and unironically pushing for incremental rewrites in Rust. Not because it is perfect: I've written and debugged my share of dangling pointer bugs in unsafe Rust code too - but because it is at least better, and provides me with tools to fight the good fight. And if, from time to time, you find my voice amongst the nitpickers of attempts at C++ "improvements", it's perhaps because the attempt has failed, and I would rather not have others waste their time like I have on false promises. Granted, such warnings are unlikely to work: the alure of something that might ward off yet more late nights chasing yet more heisenbugs in yet another C++ codebase caused by coworkers, third parties, those long gone, or perhaps worse - by me - is just too promising. But it might. Show me real bugs, in real codebases, caught in bulk where existing tools have failed, and you will have my undivided attention.

by net_ 4y ago

otabdeveloper4 4y ago

> programming is hard, let's go (language) shopping instead

guitarbill 4y ago

It doesn't feel much different to any other language that people have been burned by (e.g. Javascript). I have some bad C++ experienced, and I know enough programmers I respect who stick to C over C++. Of course it's difficult to equate that kind of advice/feedback to negative comments on HN. But often, there's some kernel of truth there. So while there's some merit to C++, the criticism can equally be valid. And keeping the underlying complexity of C++ (similar to how Carbon will) might not meaningfully simplify development).

einpoklum 4y ago
> I have some bad C++ experienced, and I know enough programmers I respect who stick to C over C++. Do you know such people who work on large software systems, as opposed to, say, micro-controller firmware, or kernel drivers and such? (Asking as a person who maintains an important(ish) C library for embedded coders: https://github.com/eyalroz/printf https://github.com/eyalroz/printf)
- Galanwe 4y ago
  On the top of my head, for large open source C codebases that are not system/kernel/controller I guess Python, Ruby and Redis would be good examples. I do myself fall in the category of people sticking to C over C++. I used to love C++ back until c++03, then completely hated the whole "new generation c++" orientation that started with c++11 and pretty much decided to not touch c++ anymore.
  - jcelerier 4y ago
    I think that "large" really needs to be defined here. CPython is 350kloc of C. I have seen C++ codebases with more source files than there are lines of code in that. Just the "base" module of Qt is ~4million loc
- 1024core 4y ago
  > Do you know such people who work on large software systems, as opposed to, say, micro-controller firmware, or kernel drivers and such? Redis is written entirely in C.
  - summerlight 4y ago
    I don't think that Redis qualifies as a large software system in the modern standard. In fact, it's popular because it's simple, small and understandable compared to its competitors which comprises of many millions of lines of code.
  - jrockway 4y ago
    I really don't think Redis is a large software system. Things like Firefox, Chrome, AAA games, etc. are what I'd call large C++ systems.
  - einpoklum 4y ago
    Redis is ~200K lines of C code, so it's relevant project-size-wise, but - redis was started in C, right? It's not like developers now have the option to "go C++" without a company-wide decision. Still, if could quote Redis developers making the GP's claim, that would count.
- mek6800d2 4y ago
  I used to work for a company whose product was a fairly large satellite control center software system (and we could supply hardware if needed), written in C++. It's used for a lot of commercial fleets. For example, back in the 2000s, when I worked on it, it was used for CDRADIO/Sirius's fleet. (I don't know if it's still used for SiriusXM's Sirius satellites, if any.) I liked C++ in some ways, but as a whole, I think, C++ didn't reduce -- and may have increased -- the complexity of our software compared to the complexity of an equivalent C implementation. (I'm talking about the complexity of the software itself, not the complexities of the tasks it was doing.) The distribution of the complexity in the code would just have been different between the two implementations. IMHO. So I mostly stick with C or other non-C++ languages now. Of course, C++ has expanded and changed greatly since then.
  - ncmncm 4y ago
    You would be very pleasantly surprised at how programming in C+ is, today, vs. pre-C++11. With C++20, the language has got even nicer to use.
    - throwaway894345 4y ago
      I remember really enjoying C++ circa 2012, but I really hated scripting my own build tooling via CMake or manually wrangling dependencies. This was the stuff that pushed me out of C++. Fortunately, Go had just hit 1.0 and it fixed many of the problems out of the gate, and I didn’t really need the performance that C++ offered.
      - ncmncm 4y ago
        Even CMake has got less annoying.
        throwaway894345 4y ago
        It had nowhere to go but up! (: Jokes aside, I’m glad to hear it.
- guitarbill 4y ago
  Some software for storage products is C. I imagine other conservative industries could be similar. But I have also heard that although the senior devs would prefer to stick to C for technical reasons, they have started to use/embrace C++ for hiring reasons (since many grads are taught C++). So I wouldn't be surprised if finding "pure" C codebases/ones without C++ is getting harder. The eco-system around C++ (e.g. test frameworks) certainly seemed healthier. It's been a few years though, so I might not have a good picture any more.

bowsamic 4y ago

I agree, and I don't think it's as hard or complex as people make it out to be

zozbot234 4y ago

> C++ is (I'm guessing) currently holding up an order of magnitude more applications than whatever you think is better than it. So what. No one's going to rewrite all of those million lines of code in New C++, or whatever they call this incompatible syntax. It's just a distraction from more relevant efforts.

pavlov 4y ago
New code can be written in the new syntax, with full access to existing libraries. I could easily see a company like Meta adopting this. They have both a huge amount of C++ code as well as actively developed guidelines and internal libraries that make use of cutting-edge features.
pelario 4y ago
From the link: "I'm sharing this work because I hope to start a conversation about what could be possible within C++’s own evolution to rejuvenate C++, now that we have C++20 and soon C++23 to build upon." Clearly this is relevant for c++ itself (coming from Sutter), so I'd say it's quite unfair/misguided to call it "just a distraction from more relevant efforts."
the-smug-one 4y ago
If you've got 10^6 LoC of a product that will be developed and maintained for 10+ more years then you can slowly replace it with this.
zbird 4y ago
Of course they will. What they are less likely to do is to rewrite it in a completely different language (e.g. Rust.) C++ became popular in the first place because it could easily go along with C. No need to rewrite in bulk.
- stormbrew 4y ago
  The thing is that C is still the lingua franca abi, so there's still no need to rewrite in bulk, you can still just use the same C libraries in another language, and rust is particularly well suited to doing that in roughly the same ways C++ is. What's getting harder and harder to see now is why, if you need to write new or rewrite now, you'd choose C++ over rust. In the long run that's a recipe for only the most gnarly old codebases being written in c++ and no one wanting to touch them.

benj111 4y ago

Familiarity breeds contempt? I'm sure many would dislike rust if they were forced to use it. Same with python, etc, etc, etc. I'm not saying the criticisms are wrong per se, but the reason we have so many languages is probably because there's no 'right' language.

uoaei 4y ago

zhxshen 4y ago

The text-include compilation model is broken, larger projects pay dearly for this, and thanks to C++'s very long history & very long feature list, there is a veritable Babel of feature subsets & compiler opts to choose from. Adding new dialects and features is not an improvement here.

klodolph 4y ago
This is what the "modules" feature in C++20 addresses. People are complaining about modules a lot, I think because the spec is a little complicated... but the spec is a little complicated because the problem is a little complicated, and you can't pretend that complexity doesn't exist when you're writing the spec. (There are some other complaints about the modules system. It wasn't going to please everyone.) New dialects and features were getting added to JS all the time, but what happens is people writing JS libraries or tooling would watch how far these features spread in their users' browser compile base, and many of these various features would never even make it into popular JS runtimes, while others are everywhere now. I think it's a reasonable model for development--lots of people trying to improve things, the community slowly sifts it out, and the standards are the most conservative of all.
- zhxshen 4y ago
  > because the spec is a little complicated Patching over the old work--hopefully without breaking anything--always is. I'm just stating that much of the hostility toward C++ comes from the fact that we have so many superior options to choose from now--options which profited from the lessons C++ learned the hard way, and incorporated them into v1 instead of patching them in as options at v23. And this is not to strikeforce anyone with a "Rewrite it in Rust!", but to suggest that C++ is maybe not the best choice for new work in 2022.
- forrestthewoods 4y ago
  People complain about modules because they only exist on paper. Not a single compiler supports the standard library as a module. No compiler has full support for modules. Modules are a C++20 feature that isn't usable in real projects in 2022. And there's no signs that modules will be ready anytime soon.

alar44 4y ago

I will probably get some flack for this but it's an effect of the Python generation. When you can pull in some libraries and build some bloated slow as hell code in minutes, no one cares what's under the hood. The tradeoff from performance (easily 1000s of times, I've seen it swapping out simple python libs for c++, specifically changing dicts to linked lists) to ease of slapping things together makes me sad daily.

lolinder 4y ago
Why would a trade-off make you sad? For most code that gets written, being able to quickly make something work is far more important than a 1000x increase in performance. Some projects do need performance, and for those no one should choose Python. For all the others, I'm glad Python exists.
- alar44 4y ago
  Because there's lots of projects out there with absolutely horrible optimization. Doing stupid shit inside of loops etc. It turns into the blind leading the blind and churns out bad code.

pjmlp 4y ago

C++ is a great language, the sub culture that keeps unsafe C patterns alive in the language, not so much. Example, back in the heyday of C++ frameworks bundled with compilers, bounds checking strings and collection arrays were the default. Nowadays you either call at(), have your own bounded checked types, or enable the debug library, but naturally without influence on 3rd party depedencies.

staticassertion 4y ago

> Clearly it has upsides, All that you've indicated is that it's used a lot, which is obviously because it has decades on every other option. Anyway, I love Herb Sutter and I love this work he's doing. Awesome stuff.

throwaway894345 4y ago

“Holding up an order of magnitude more applications … clearly it has upsides”. It’s holding up lots of applications because better languages didn’t exist at the time those projects were started, and it’s rarely feasible to switch languages. Specifically, a lot of people look to Rust to unseat C++ for new applications, but it will take a while for Rust to mature with respect to libraries (e.g., game engines) and mindshare in those industries. But even then, old languages have tons of staying power by virtue of age.

YZF 4y ago
I'm not super familiar with Rust, do you have SSE/AVX intrinsics (others?)? Can you write assembly embedded in Rust code? How does rust stack in terms of performance? https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/... looks quite decent, but overall Rust is still behind? So if I am in an area where performance (or cost/energy) is king then I'd still pick C++.
- agersant 4y ago
  > do you have SSE/AVX intrinsics (others?)? Yes. https://docs.rs/simd/latest/simd/ https://docs.rs/simd/latest/simd/ > Can you write assembly embedded in Rust code? Also yes. https://doc.rust-lang.org/reference/inline-assembly.html https://doc.rust-lang.org/reference/inline-assembly.html
- the_jesus_villa 4y ago
  I don't know the answers to all of your questions, but >Can you write assembly embedded in Rust code? Yes, I've done this several times. It looks like this: https://doc.rust-lang.org/rust-by-example/unsafe/asm.html https://doc.rust-lang.org/rust-by-example/unsafe/asm.html
- dento 4y ago
  SIMD intrinsics exist, although currently require nightly compiler on non-x86 targets: https://doc.rust-lang.org/1.29.0/core/arch/x86/index.html https://doc.rust-lang.org/1.29.0/core/arch/x86/index.html Inline assembly: https://rust-lang.github.io/rfcs/2873-inline-asm.html https://rust-lang.github.io/rfcs/2873-inline-asm.html Performance is almost identical, even the linked benchmark is quite even.

mattgreenrocks 4y ago

My theory is that the Internet generally hates multi-paradigm languages (Scala!). Key phrase there is “the Internet,” which is a euphemism for “people who write in the comment section.” They aren’t a representative sample, just a vocal one. There are plenty of good reasons to hate on C++, but that’s conflated with a lot of “real hacker” signaling. Most takes on C++ lament that it isn’t C, or is too complex. Rust is a quality replacement for C++, but it doesn’t succeed on either of those counts either. All new code I write is in Rust or Haskell. If I need to do something weird, like with DynamoRIO, C++ it is.

riffraff 4y ago
Python and Ruby were considered multiparadigm languages once, and the internet didn't hate them at all. I think "the internet" tends to complain about languages which have accrued complexity over time, and contain parts that are now considered bad but still lurk in the shadows tripping you up. Scala, C++, perl and others seem to fall into this category.
- throwaway894345 4y ago
  I think the Internet doesn’t like languages that don’t have good, strong opinions that will help you find a successful path. C++ just says “here’s every feature we’ve ever heard of; good luck!” whereas Go has strong opinions about how you should build software and while they might change people, they really do put you on the right track. Rust is closer to Rust, but it has so many features that it still takes some time to figure out the happy path—fortunately, the Rust community makes up for a lot of that with excellent documentation (e.g., the Rust Book) and helpful, friendly forums.
  - mattgreenrocks 4y ago
    Yes, this is what I'm getting at. There's a very real desire for things to just be laid out for you, and much less regard for whether the workflow/tradeoffs associated with that beget quality software in the process. It is hard to not see this as an army of advanced beginners unconsciously trying to avoid doing the work required to level up.

Volker_W 4y ago

> C++ is (I'm guessing) currently holding up an order of magnitude more applications than whatever you think is better than it. You could say the same thing about COBOL. (Not that I think that C++ is as bad as COBOL.)

0x457 4y ago

I think not many people ever got properly introduced to C++. Some probably only saw it during their format education, and it's most likely been taught like C with classes and/or they had to use for stupid things. There are also many forms of C++, there is your "old and regular" C++, game dev C++, there is modern C++, then there is "I only know C, but sure I can write C++" C++. Pulling dependencies is not as simple as `npm i boost`. Communities are small, segmented and not welcoming to newbies. Absolute madness with build tools. I've never worked with CMake myself until last year, and I haven't so frustrated. As for how many applications using C++ that's not really an argument — C++ was literally the only choice for many of them at that time.

FerociousTimes 4y ago
I echo the same sentiment here but mainly for C language as If my memory serves me right, I didn't have any encounter with C++. My experience was negative overall and traumatic to some extent and I wouldn't rule out that some who were first exposed to the language in college or even HS share the same aversion and feel scarred and haunted forever by that Blue Ghost.
spookie 4y ago
Not really an argument? The C/C++ ecosystem is so well established that even today you don't have a choice in a lot of contexts. If that doesn't show the power of a language, I don't know what can. I don't really think the community is toxic or unwelcoming, more like people are too used to ctrl+c ctrl+v their way out of problems. Nothing against that, I'm the same way, but it really is a matter of taking your time with the language. I've honestly learned to applaud most rust fanatics because of this, at least they are passionate about learning athe language inside/out.
- throwaway894345 4y ago
  Where is C++ the only choice? Gamedev seems like the closest—as far as I know, most AAA games aren’t using C, but I think maybe many are using C# via Unity (I’m not familiar with the gamedev space)? In the embedded world, C still reigns supreme. Maybe in the world of high frequency trading? But these seem to be fewer and fewer and Rust seems increasingly likely to be a contender in these domains.

ryukoposting 4y ago

C++'s main upside is that it's the least common denominator. Also its runtime is friendly to embedded systems (kind of). I welcome good replacements for C++'s syntax, because it's genuinely terrible.

CamperBob2 4y ago

That's true, but at the same time, modern C++ bears about the same resemblance to the C++ that many (if not most) of us learned years ago, as modern English bears to Middle English. People have been trying to make the language safer and more palatable for multiple decades now, so it seems reasonable to allow Sutter to have a go at it.

cplusplusfellow 4y ago

I’m truly thankful in my life for Sutter doing the work he does to make this language better. He is a giant.

asveikau 4y ago

I came up with the following guess many years ago: There are people who are totally unproductive at C++ and find it scary, mainly because they are not very exposed to it. They assume everybody is as uncomfortable and unproductive with it as they are. Nay, it is impossible for anyone to be productive with it, simply because they aren't. They will attack evidence that somebody has done well with it, because it is some defense of ego for them. There are other complaints about C++ beyond this of course, with validity, and many of them from old timers and people who bitterly complained about it for decades from a place of knowledge and experience. People have been complaining about ugliness of C++ for longer than my own career. However, as more and more people come up in the post-C++-as-fashionable era, I think this above theory is more and more the bulk of the complaints.

hvs 4y ago

C++ is like the English language. Extraordinarily popular, hard to learn, and full of weird cruft. You can write amazing things in it as well as terribly unsafe garbage.

account42 4y ago
English is not particularly hard to learn.

MaulingMonkey 4y ago

> Clearly it has upsides, so it's baffling to me when people greet attempts to reduce the downsides with either "This doesn't make sense, just scrap it for something else" or endless nitpicks about the approach chosen. People have been working to reduce the downsides of C++ for decades at this point, and the results are incredibly lackluster, and frequently only work in trivial toy examples - if even then. Every now and then I try out the latest and greatest I can find in terms of dangling pointer prevention, and find myself confused as to if I've even enabled the proper checks, when even my trivial toy examples fail to trigger said checks, only to be horrified when I in fact have enabled said checks and gained nothing. I, too, welcome any useful results. The problem is: I don't actually find the results useful. I get told garbage like "C++ is safe now!" by people who apparently don't know any better, for things underperforming existing static analysis tools from over a decade ago. It's a distraction, a false promise, and a waste of my time - which could be better spent reviewing C++ code, improving existing static analysis coverage, or going full ham and unironically pushing for incremental rewrites in Rust. Not because it is perfect: I've written and debugged my share of dangling pointer bugs in unsafe Rust code too - but because it is at least better, and provides me with tools to fight the good fight. And if, from time to time, you find my voice amongst the nitpickers of attempts at C++ "improvements", it's perhaps because the attempt has failed, and I would rather not have others waste their time like I have on false promises. Granted, such warnings are unlikely to work: the alure of something that might ward off yet more late nights chasing yet more heisenbugs in yet another C++ codebase caused by coworkers, third parties, those long gone, or perhaps worse - by me - is just too promising. But it might. Show me real bugs, in real codebases, caught in bulk where existing tools have failed, and you will have my undivided attention.