10 ms·

Seems like C++ is having an identity crisis lately

api 4y ago
Rust is eating it in systems and Go for applications. IMHO nothing but Rust or Go has any merit as a replacement unless it also bring the same safety. A fully unsafe language in 2022 is dumb. (Fully unsafe, not optional unsafety which may be needed in a systems language.)
- 3a2d29 4y ago
  "A fully unsafe language in 2022 is dumb." I think this is a subtweet at Zig, and while I am not a zig developer, I will point something out that everyone forgets (to defend C++ and Zig and the like): Some apps don't need memory safety. For example a single player game or application that runs just on your own machine, memory safety would just be another type of bug. If dealing with Rust's ownership rules is annoying and you don't want a GC, then you can certainly use an unsafe language. Not all apps are websites and browsers. I would also add (I could be wrong here) but I think things written in web assembly can also be unsafe, as the memory is in a sandbox. I think I heard this once, but I could be wrong.
  - strictfp 4y ago
    > Some apps don't need memory safety. Maybe not, but it's still a big pain in the butt to avoid bugs in that area. I imagine that static analysis for memory safety would be something that most developers would use in existing unsafe languages if they could.
    - pjmlp 4y ago
      Lint was created for C in 1979… to this day most devs ignore static analysis tooling for C and C++.
      - KerrAvon 4y ago
        Static analysis can be excellent, but it doesn't solve the whole problem.
        pjmlp 4y ago
        Indeed, still using it is better than nothing.
        patrick451 4y ago
        For a lot of applications, that doesn't matter. It solves enough of the problem.
  - api 4y ago
    > Some apps don't need memory safety. Even apps that run locally and don’t talk to the net can be vulnerable. How many break ins happen via bugs in PDF viewers, office packages, and media players? Look it up. PDF and spreadsheet vulnerabilities are very common. Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs. The latter are not ruled out in Go or Rust but they are profoundly less likely to occur, making code that actually takes advantage of modern hardware much easier to write. After learning Rust and after having used C++ very heavily for years I can say that Rust is far more productive.
    - azakai 4y ago
      > PDF and spreadsheet vulnerabilities are very common. True. The issue is that they operate on complex input that can arrive from anywhere. So if you download a malicious PDF file it can exploit you. But GP's other example is valid: A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program. There is room for languages like Zig. There is also the potential for it to be used in improper places, but so far the majority of applications I've heard of seem reasonable to me. > Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs. Also true. But there are the other usual tradeoffs, such as that a language focused on simplicity and correctness, like Zig, might reduce other sources of bugs. Some developers might be more productive with Rust, others with Go, others with Zig. I don't think there's a single answer here. As an example of another related tradeoff, fast compile times often help debugging, which is an advantage of Go and Zig.
      - KerrAvon 4y ago
        > A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program. Nothing is that isolated anymore. Can you find a modern single-player game on Steam that doesn't talk to the network for analytics or DLC or sending crash reports to the developer? I'm sure they exist, but they're likely exceptionally rare. For Zig to be helpful in the modern world, it will need memory safety guarantees and it will need them on by default. It's totally OK if those are easier to switch off than in Rust so that you can do the low-level things performantly and easily. But you have to start from a default position of safety.
  - littlestymaar 4y ago
    > Some apps don't need memory safety. Even setting security considerations aside, as soon as you have users, using a non-memory-safe language means having users reporting very unhelpful “bun crashes at startup with "segmentation fault"”and good luck to figure out what's going on. > I think this is a subtweet at Zig Why do you think it's especially aimed at Zig? Zig is only one among others, like Carbon, or Cppfront discussed here.
    - 3a2d29 4y ago
      I would agree that seg faults are not fun to debug, but if you think you can be speed up production and get the product done several orders of magnitude faster without ownership rules AND you can't use a GC, I do think it could be worth the trade-off. > Why do you think it's especially aimed at Zig? I honestly don't use zig so I really don't have a horse in the race, but when I read: "nothing but Rust or Go has any merit as a replacement unless it also bring the same safety. A fully unsafe language in 2022 is dumb" That seems to be targeted at replacing C++, which both Carbon and CppFront are not doing per se. Zig is the next big "low level replacement language" (that isn't Rust or Go) that HN seems to chat about so I took a guess. Again, I don't think that's too relevant to my point (although I am curious if OP wants to weigh in on what they meant).
      - littlestymaar 4y ago
        > but if you think you can be speed up production and get the product done several orders of magnitude faster without ownership rules If you genuinely believe that Rusts rules slow developers down by “several ordrers of magnitude” (which litterally means: “makes you 100 times slower or more”) then you've probably listened/read way to much anti-rust discourse for your own good… Rust has a learning curve and in the beginning you're obviously going to be slowed down by the learning process, but for 99% of the tasks[1] once you've gone past the initial learning period, the rules aren't slowing you down since you've internalized them, and compiler errors end up being mostly about things that would have caused a memory bug in other low-level languages. [1]: that is, everything but custom graph data structures, which are really hard to get right without a GC anyway.
  - pjmlp 4y ago
    Only because liability is still not a thing in software as in other regulated domains. > Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. -- C.A.R Hoare on his Turing award speech in 1981.
    - 3a2d29 4y ago
      Against the law cause if you do this on a bridge, people die. If a play Civ V and it crashes, I just a bit mad. I will acknowledge though good engineering practices are important, maybe my perspective of "tolerance" of these bugs when they are isolated is missing the point.
      - pjmlp 4y ago
        If I play Civ V and it crashes, I want my money back, just like I won't stand a broken appliance. Thankfully App stores are already making this point clear to the industry.
        3a2d29 4y ago
        Doesn’t this counter your first point? A broken appliance isn’t against the law. Second, I think data shows most people don’t return games after 1 crash. In fact, I think getting to market fast is a bigger factor for profit.
        pjmlp 4y ago
        Not refunding a customer for selling a broken product is against the consumer law in plenty of jurisdictions. People still don't do it because they have been taught that software is special, they have to put up with broken products, that is just how things are with computers.
  - charcircuit 4y ago
    >memory safety would just be another type of bug A bug that can be costly to reproduce and fix and has the affect of terrible UX and losing unsaved progress. If I had to choose a category of bugs to tolerate memory safety bugs would be near the bottom of the list.
    - jstimpfle 4y ago
      It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them? I know that in the domains that I'm interested in, I would be way miserable programming in something like e.g. Java, because I've figured out certain patterns that I know will work in a memory-unsafe language with very little friction, but that cannot be simply be translated to Java because of e.g. reference semantics. The same probably holds for other approaches to safety, like Rust. I'm not interested anymore in tight opinionated approaches to problem solving. I _love_ void-pointers and memcpy'ing stuff because these let me do abstraction with very low friction. Getting the job done very quickly, with very very low rate of bugs, and those get quickly fixed. (I'm not making a statement about multi-million line projects in corporate environments. This is about the situations that I run into, personally).
      - charcircuit 4y ago
        >how do you explain so many programmers still willingly choosing them? Lack of education + Legacy software / programmers / education material.
        api 4y ago
        It’s also a dumb macho thing. “Real programmers…” Yeah and I bet real home builders don’t use nail guns, prefab sections, or tape measures. They just eyeball it all and use wooden pegs and hammers.
      - kouteiheika 4y ago
        > It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them? Honestly? And this might be a hot take - exactly the same way as I'd explain people rejecting structured programming way back in the day. It was the new thing on the block and people were not used to it, and preferred to just sprinkle GOTOs in their program just like they always used to do rather than learning a new paradigm. As someone who used to professionally program in C++ on an expert level in the past and now has completely switched to Rust I can tell you that (at least subjectively for me) Rust is way more productive than C++ ever was. Once you internalize how the language works the limitations of Rust just disappear. You learn how to instinctively write code that's idiomatic, and it just stops slowing you down. But it also gives you a ton of new features that end up speeding you up compared to C++, e.g. sum types, pattern matching, cargo, great standard library, destructive moves, proper modules, #[derive], good error messages, etc. Memory safety can also be significant productivity boost because you can (or at least I do) just churn out code without thinking about it too much and just rely on the compiler to make sure that it's memory safe. Can this code trigger use-after-free? Is this iterator valid? What's the lifetime of this pointer? Instead of thinking about all of these you can use those brain cells for something else.
  - astrange 4y ago
    A single player game still accesses the network. Consoles that trust their game code regularly get jailbroken through eg overflows in a game's save file formats. Plus it's only single player until they decide to add multiplayer…
rramadass 4y ago
Nah... It is just the ISO committee and its members mucking about. Many of us don't agree with the way the committee has been "evolving" the language and then mandating "the one true way to do Modern C++". At least with this "syntax 2" thing they will leave the language alone.
echelon 4y ago
C++ is getting the Perl treatment. Perl had Ruby, Python, and PHP attacking it. C++ has Rust, Go, Nim, and Swift (albeit that only Rust is a direct challenge, the others are taking market share for things that used to be C++). I've even seen people using Vala in new places. Perl was hard to use. The new languages addressed many of the ergonomics, semantics, and design concerns. Rust addresses a lot of C++'s dangerous baggage. Perl had novel tooling at the time, but eventually wound up behind. Newer languages brought more to the table. Rust has Cargo. Perl tried evolving for a long time. Eventually birthed a new language altogether (Raku), albeit that the old language still receives updates. (Python also saw this.) Google recently unveiled Carbon. Now there's Cppfront. The C++ language committee is doing different things... It's a question of which ecosystem evolves faster and ultimately which ecosystem attracts more fresh blood as old timers age out. AFAICT, younger developers are flocking to Rust instead of C++. There are a bunch of Rustlang streams on Twitch.
- mlinksva 4y ago
  That's an interesting analogy that I hadn't seen before, simplified as Perl : Python :: C++ : Rust in terms of conjectural market adoption. As someone who did a lot of Perl in web 1.0 times, and haven't really been a full time programmer in a long time but occasionally have since written Ruby, Python, and PHP, but never really felt those languages were that huge of improvements over Perl (certainly now their ecosystems are, but I'd love a much better entrant to successfully "attack" Python), and would sometimes wonder what if Perl had just managed to evolve significantly instead...makes me appreciate and even root for efforts to "make C++ 10x simpler, safer, and more toolable" like this one or perhaps Carbon, even though Rust does seem like a huge improvement.
  - cageface 4y ago
    I wrote a lot of Perl in the first dotcom era and was very happy to switch to Python and Ruby as soon as I had a chance. There were some nice things about Perl but it was just too hard to maintain a large, active perl codebase with multiple engineers making commits. Perl coasted along for a long time on the momentum of CPAN but it wasn't enough. I think the C++ analogy makes sense. How many programmers entering the field today are choosing to learn C++ when they have so many other choices without all of C++'s baroque complexity and footguns?

api 4y ago

Rust is eating it in systems and Go for applications. IMHO nothing but Rust or Go has any merit as a replacement unless it also bring the same safety. A fully unsafe language in 2022 is dumb. (Fully unsafe, not optional unsafety which may be needed in a systems language.)

3a2d29 4y ago
"A fully unsafe language in 2022 is dumb." I think this is a subtweet at Zig, and while I am not a zig developer, I will point something out that everyone forgets (to defend C++ and Zig and the like): Some apps don't need memory safety. For example a single player game or application that runs just on your own machine, memory safety would just be another type of bug. If dealing with Rust's ownership rules is annoying and you don't want a GC, then you can certainly use an unsafe language. Not all apps are websites and browsers. I would also add (I could be wrong here) but I think things written in web assembly can also be unsafe, as the memory is in a sandbox. I think I heard this once, but I could be wrong.
- strictfp 4y ago
  > Some apps don't need memory safety. Maybe not, but it's still a big pain in the butt to avoid bugs in that area. I imagine that static analysis for memory safety would be something that most developers would use in existing unsafe languages if they could.
  - pjmlp 4y ago
    Lint was created for C in 1979… to this day most devs ignore static analysis tooling for C and C++.
    - KerrAvon 4y ago
      Static analysis can be excellent, but it doesn't solve the whole problem.
      - pjmlp 4y ago
        Indeed, still using it is better than nothing.
      - patrick451 4y ago
        For a lot of applications, that doesn't matter. It solves enough of the problem.
- api 4y ago
  > Some apps don't need memory safety. Even apps that run locally and don’t talk to the net can be vulnerable. How many break ins happen via bugs in PDF viewers, office packages, and media players? Look it up. PDF and spreadsheet vulnerabilities are very common. Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs. The latter are not ruled out in Go or Rust but they are profoundly less likely to occur, making code that actually takes advantage of modern hardware much easier to write. After learning Rust and after having used C++ very heavily for years I can say that Rust is far more productive.
  - azakai 4y ago
    > PDF and spreadsheet vulnerabilities are very common. True. The issue is that they operate on complex input that can arrive from anywhere. So if you download a malicious PDF file it can exploit you. But GP's other example is valid: A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program. There is room for languages like Zig. There is also the potential for it to be used in improper places, but so far the majority of applications I've heard of seem reasonable to me. > Then there’s the productivity gain you get by not having to spend hours debugging obscure memory and threading bugs. Also true. But there are the other usual tradeoffs, such as that a language focused on simplicity and correctness, like Zig, might reduce other sources of bugs. Some developers might be more productive with Rust, others with Go, others with Zig. I don't think there's a single answer here. As an example of another related tradeoff, fast compile times often help debugging, which is an advantage of Go and Zig.
    - KerrAvon 4y ago
      > A singleplayer game running locally will only run the game assets from the developer. The user input (in almost all games) is very limited. Exploits are not a major issue in such a program. Nothing is that isolated anymore. Can you find a modern single-player game on Steam that doesn't talk to the network for analytics or DLC or sending crash reports to the developer? I'm sure they exist, but they're likely exceptionally rare. For Zig to be helpful in the modern world, it will need memory safety guarantees and it will need them on by default. It's totally OK if those are easier to switch off than in Rust so that you can do the low-level things performantly and easily. But you have to start from a default position of safety.
- littlestymaar 4y ago
  > Some apps don't need memory safety. Even setting security considerations aside, as soon as you have users, using a non-memory-safe language means having users reporting very unhelpful “bun crashes at startup with "segmentation fault"”and good luck to figure out what's going on. > I think this is a subtweet at Zig Why do you think it's especially aimed at Zig? Zig is only one among others, like Carbon, or Cppfront discussed here.
  - 3a2d29 4y ago
    I would agree that seg faults are not fun to debug, but if you think you can be speed up production and get the product done several orders of magnitude faster without ownership rules AND you can't use a GC, I do think it could be worth the trade-off. > Why do you think it's especially aimed at Zig? I honestly don't use zig so I really don't have a horse in the race, but when I read: "nothing but Rust or Go has any merit as a replacement unless it also bring the same safety. A fully unsafe language in 2022 is dumb" That seems to be targeted at replacing C++, which both Carbon and CppFront are not doing per se. Zig is the next big "low level replacement language" (that isn't Rust or Go) that HN seems to chat about so I took a guess. Again, I don't think that's too relevant to my point (although I am curious if OP wants to weigh in on what they meant).
    - littlestymaar 4y ago
      > but if you think you can be speed up production and get the product done several orders of magnitude faster without ownership rules If you genuinely believe that Rusts rules slow developers down by “several ordrers of magnitude” (which litterally means: “makes you 100 times slower or more”) then you've probably listened/read way to much anti-rust discourse for your own good… Rust has a learning curve and in the beginning you're obviously going to be slowed down by the learning process, but for 99% of the tasks[1] once you've gone past the initial learning period, the rules aren't slowing you down since you've internalized them, and compiler errors end up being mostly about things that would have caused a memory bug in other low-level languages. [1]: that is, everything but custom graph data structures, which are really hard to get right without a GC anyway.
- pjmlp 4y ago
  Only because liability is still not a thing in software as in other regulated domains. > Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law. -- C.A.R Hoare on his Turing award speech in 1981.
  - 3a2d29 4y ago
    Against the law cause if you do this on a bridge, people die. If a play Civ V and it crashes, I just a bit mad. I will acknowledge though good engineering practices are important, maybe my perspective of "tolerance" of these bugs when they are isolated is missing the point.
    - pjmlp 4y ago
      If I play Civ V and it crashes, I want my money back, just like I won't stand a broken appliance. Thankfully App stores are already making this point clear to the industry.
      - 3a2d29 4y ago
        Doesn’t this counter your first point? A broken appliance isn’t against the law. Second, I think data shows most people don’t return games after 1 crash. In fact, I think getting to market fast is a bigger factor for profit.
        pjmlp 4y ago
        Not refunding a customer for selling a broken product is against the consumer law in plenty of jurisdictions. People still don't do it because they have been taught that software is special, they have to put up with broken products, that is just how things are with computers.
- charcircuit 4y ago
  >memory safety would just be another type of bug A bug that can be costly to reproduce and fix and has the affect of terrible UX and losing unsaved progress. If I had to choose a category of bugs to tolerate memory safety bugs would be near the bottom of the list.
  - jstimpfle 4y ago
    It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them? I know that in the domains that I'm interested in, I would be way miserable programming in something like e.g. Java, because I've figured out certain patterns that I know will work in a memory-unsafe language with very little friction, but that cannot be simply be translated to Java because of e.g. reference semantics. The same probably holds for other approaches to safety, like Rust. I'm not interested anymore in tight opinionated approaches to problem solving. I _love_ void-pointers and memcpy'ing stuff because these let me do abstraction with very low friction. Getting the job done very quickly, with very very low rate of bugs, and those get quickly fixed. (I'm not making a statement about multi-million line projects in corporate environments. This is about the situations that I run into, personally).
    - charcircuit 4y ago
      >how do you explain so many programmers still willingly choosing them? Lack of education + Legacy software / programmers / education material.
      - api 4y ago
        It’s also a dumb macho thing. “Real programmers…” Yeah and I bet real home builders don’t use nail guns, prefab sections, or tape measures. They just eyeball it all and use wooden pegs and hammers.
    - kouteiheika 4y ago
      > It seems like in terms of subjective productivity, memory-unsafe languages have going for them a lot. Otherwise how do you explain so many programmers still willingly choosing them? Honestly? And this might be a hot take - exactly the same way as I'd explain people rejecting structured programming way back in the day. It was the new thing on the block and people were not used to it, and preferred to just sprinkle GOTOs in their program just like they always used to do rather than learning a new paradigm. As someone who used to professionally program in C++ on an expert level in the past and now has completely switched to Rust I can tell you that (at least subjectively for me) Rust is way more productive than C++ ever was. Once you internalize how the language works the limitations of Rust just disappear. You learn how to instinctively write code that's idiomatic, and it just stops slowing you down. But it also gives you a ton of new features that end up speeding you up compared to C++, e.g. sum types, pattern matching, cargo, great standard library, destructive moves, proper modules, #[derive], good error messages, etc. Memory safety can also be significant productivity boost because you can (or at least I do) just churn out code without thinking about it too much and just rely on the compiler to make sure that it's memory safe. Can this code trigger use-after-free? Is this iterator valid? What's the lifetime of this pointer? Instead of thinking about all of these you can use those brain cells for something else.
- astrange 4y ago
  A single player game still accesses the network. Consoles that trust their game code regularly get jailbroken through eg overflows in a game's save file formats. Plus it's only single player until they decide to add multiplayer…

rramadass 4y ago

Nah... It is just the ISO committee and its members mucking about. Many of us don't agree with the way the committee has been "evolving" the language and then mandating "the one true way to do Modern C++". At least with this "syntax 2" thing they will leave the language alone.

echelon 4y ago

C++ is getting the Perl treatment. Perl had Ruby, Python, and PHP attacking it. C++ has Rust, Go, Nim, and Swift (albeit that only Rust is a direct challenge, the others are taking market share for things that used to be C++). I've even seen people using Vala in new places. Perl was hard to use. The new languages addressed many of the ergonomics, semantics, and design concerns. Rust addresses a lot of C++'s dangerous baggage. Perl had novel tooling at the time, but eventually wound up behind. Newer languages brought more to the table. Rust has Cargo. Perl tried evolving for a long time. Eventually birthed a new language altogether (Raku), albeit that the old language still receives updates. (Python also saw this.) Google recently unveiled Carbon. Now there's Cppfront. The C++ language committee is doing different things... It's a question of which ecosystem evolves faster and ultimately which ecosystem attracts more fresh blood as old timers age out. AFAICT, younger developers are flocking to Rust instead of C++. There are a bunch of Rustlang streams on Twitch.

mlinksva 4y ago
That's an interesting analogy that I hadn't seen before, simplified as Perl : Python :: C++ : Rust in terms of conjectural market adoption. As someone who did a lot of Perl in web 1.0 times, and haven't really been a full time programmer in a long time but occasionally have since written Ruby, Python, and PHP, but never really felt those languages were that huge of improvements over Perl (certainly now their ecosystems are, but I'd love a much better entrant to successfully "attack" Python), and would sometimes wonder what if Perl had just managed to evolve significantly instead...makes me appreciate and even root for efforts to "make C++ 10x simpler, safer, and more toolable" like this one or perhaps Carbon, even though Rust does seem like a huge improvement.
- cageface 4y ago
  I wrote a lot of Perl in the first dotcom era and was very happy to switch to Python and Ruby as soon as I had a chance. There were some nice things about Perl but it was just too hard to maintain a large, active perl codebase with multiple engineers making commits. Perl coasted along for a long time on the momentum of CPAN but it wasn't enough. I think the C++ analogy makes sense. How many programmers entering the field today are choosing to learn C++ when they have so many other choices without all of C++'s baroque complexity and footguns?