11 ms·

The article is about creating a potential successor to C++ in the same way JavaScript lead to TypeScript, or Java lead to Kotlin, or C lead to C++, and in givin

The article is about creating a potential successor to C++ in the same way JavaScript lead to TypeScript, or Java lead to Kotlin, or C lead to C++, and in giving those examples immediately undermining its own thought because none of those replaced the thing they came out of. Heck looking at whose still writing new code bases in what, C++ didn't even replace C, and Swift didn't replace Objective C. C++ and Switft just became "more dominant". So based on the article's own observation: no, of course not. The more interesting question is "will it stand on its own?" to which the answer is "only if it actually solves so many problems with the thing it's trying to supplant that it makes sense to give it a serious try". And C++ just... doesn't have that many real problems. It has a lot of irks, but the problems people run into are problems that others already solved, a thousand times, over the last half century, in many different ways for many different iterations of the language. Pretending you can replace C++ is like pretending you can replace cars. Not just "create EVs" but straight up replace cars. Good luck, you won't succeed if that's your goal, so hopefully you realise you need to focus on making a decent language that some folks might consider using instead of C++ for some of their work, instead of creating "the successor to C++".

hulitu 4y ago
> or C lead to C++, As "Unix haters handbook" says: C++ is to C, what lung cancer is to lung.
- TheRealPomax 4y ago
  A profoundly idiotic statement, but on-brand for that manifesto.
- RcouF1uZ4gsC 4y ago
  > As "Unix haters handbook" says As they compile their C code using a compiler written in C++. (GCC and Clang are both written in C++).
  - jcranmer 4y ago
    To be fair, that wasn't true when the Unix haters handbook was written, almost 30 years ago.
    - pjmlp 4y ago
      Nonetheless it was true that C++, C and UNIX share the same birthplace.
- guestbest 4y ago
  If a language helps a developer create a solution, it is fundamentally not a cancer.
- pjmlp 4y ago
  I love how it ignores that C++ was developed on the same place, even on the same corridor as C and UNIX devs used to work.
  - __d 4y ago
    And yet ... the C developers were never impressed by C++, and (for instance) Plan9 ended using a differently enhanced version of C, and never (I think?) had a C++ compiler.
    - pjmlp 4y ago
      The same developers that came up with Limbo and Go, somehow there is a common trend on how they see language design and the alternatives.
      - jokethrowaway 4y ago
        YMMV but Go is one of the most divisive tech out there for me. I like C++ and Rust. If I meet a dev who likes Go, I can guarantee we won't agree on much.
JustBreath 4y ago
Betteridge's law holds up as usual.
- TheRealPomax 4y ago
  It'd be quite nice if HN automatically flagged that to submitters. "Please rewrite this title to describe the article, as it is currently a question and the answer is no".
pizza234 4y ago
> And C++ just... doesn't have that many real problems. From Carbon's README: > C++ [...] is struggling to improve and meet developers' needs, as outlined above, in no small part due to accumulating decades of technical debt. Incrementally improving C++ is extremely difficult, both due to the technical debt itself and challenges with its evolution process. The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax.
- TinkersW 4y ago
  None of those are 'issues' for me. The language isn't perfect but the Carbon approach seems to not solve any meaningful issues.
  - deleted 4y ago
    [deleted]
- dralley 4y ago
  The question is not whether C++ has issues, it's whether the rest of the ecosystem cares about them as much as the Carbon devs, enough so that they would adopt Carbon instead of C++. Carbon will face the same issue as Dlang. Everyone agrees that Dlang is an improvement over C++ in many significant aspects, and a very impressive one at that, but in order to gain meaningful adoption the benefit has to be high enough to justify the pain of swimming upstream against the rest of the ecosystem. D never quite made it above that threshold, though perhaps in an alternate history where Google picked it up instead of pushing Go, it could have.
  - pornel 4y ago
    D has two problems: 1. Being "C++ but nicer" is an awkward niche. It's not differentiated enough to overcome switching costs for C++ users. It's hard to justify risks of a new language, costs of hiring and/or code rewrites just for quality of life improvements. At the same time being similar to C++ is a turn off for users who don't like C++ and look for something different. 2. D with a GC is not really competing with C++ in its core niche where C++ is irreplaceable, but rather with many many other GC languages for programs that can use almost any language. The idea of GC being optional is a hard sell, because it's an obvious switcheroo — without the GC you don't get all of the nice features, so GC-less D is even less differentiated from C++. Carbon at least avoids the second problem. I'm not sure if Carbon's new syntax and semantic tweaks are different enough.
IshKebab 4y ago
Your threshold for "replace" is too high. Did cars not replace horses because horses still exist?
kalcode 4y ago
> So based on the article's own observation: no, of course not. This had very little to the discussion. Of course it can't be replaced. Code is created by humans, and as long as we have opinions nothing gets truly replaced. Just decreased usage over time. > C++ and Switft just became "more dominant". Yup, like this. Of course a general statement is no. I have very little interest in this topic. But I seen this SAME comment a million times on anything thats new that attempts to challenge something. And as usual whether something "dethrones" something is less interesting than what changes or ideas that it offers. Just like ALL those you listed, they didn't replace any of those, but they definitely challenged the ecosystems, or improved the old ones. Naunce discussion is far more interesting. For example, why do you think Carbon won't be able to gain dominance over time? I mean I think thats a huge hurdle too.
- TheRealPomax 4y ago
  You've apparently read the reverse of what I said. I said the new thing didn't replace the old thing, and that therefore the idea that "we are doing the same, and it will replace the old thing" is nonsense. I did not say that because it can't replace it, it is therefore not worth doing. It absolutely is, like all attempts at making things that "solve the problems that C++ has" have been varying degrees of worth it. But the idea that it can, let alone will, replace the original is such an obvious "no" that the title is clickbait. Or slide-bait (since it was originally a conf. talk)
throwaway894345 4y ago
Of course, I agree that C++ isn't going to entirely disappear, but I don't understand what you mean by "C++ doesn't have many real problems, only irks". Surely the lack of memory safety is more than a mere irk--certainly Mozilla felt strongly enough to develop an entirely new programming language (as did Carbon's developers), and of course entire domains have moved away from C++ entirely (often in favor of GC languages). Yes, there remains some contingent of people for whom things like "deterministic memory management" or "immaturity for $domain" are bigger problems than those presented by C++, but that doesn't mean that C++ is without real problems, right?
jameswryan 4y ago
> And C++ just... doesn't have that many real problems. 70% of security bugs are memory safety issues. That's a lot of real problems. > It has a lot of irks, but the problems people run into are problems that others already solved, a thousand times, over the last half century, in many different ways for many different iterations of the language. People run into memory safety issues more often in new C++ code. https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet... https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html https://security.googleblog.com/2021/09/an-update-on-memory-... https://github.com/microsoft/MSRC-Security-Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf https://github.com/microsoft/MSRC-Security-Research/blob/mas... https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI... https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20presentations/Adam%20Zabrocki%20%20%20Alex%20Tereshkin%20-%20Exploitation%20in%20the%20era%20of%20formal%20verification%20a%20peek%20at%20a%20new%20frontier%20with%20AdaCore-SPARK.pdf https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20pre... https://advocacy.consumerreports.org/research/report-future-of-memory-safety/ https://advocacy.consumerreports.org/research/report-future-... https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet... https://github.com/google/sanitizers/blob/master/hwaddress-sanitizer/MTE-iSecCon-2018.pdf https://github.com/google/sanitizers/blob/master/hwaddress-s... https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language...
- dxhdr 4y ago
  > 70% of security bugs are memory safety issues. That's a lot of real problems. Run your code in a WASM sandbox or on a GPU, problem solved.
  - adgjlsfhk1 4y ago
    "Run your code in a WASM sandbox" and then your C++ is way slower (and speed is the only reason you were using C++ in the first place)
credit_guy 4y ago
> And C++ just... doesn't have that many real problems. It does not have many, but it has one and it's big. It's not memory safe. Check out this talk by Herb Sutter, around minute 43: This is the first time a government [see note] has actually issued guidance to industry broadly that was the barest paraphrase away from "where possible don't use C and C++" [ Note: in this context, the "government" is the US Department of Commerce and NIST, which, according to Herb, have issued a detailed guidance in response to the Executive Order on Cybersecurity [2]. While I couldn't find that guidance, I found one by the NSA [3], which saw quite a few comments here on HN in December last year [4] ]. [1] https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY [2] https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ https://www.whitehouse.gov/briefing-room/presidential-action... [3] https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI... [4] https://news.ycombinator.com/item?id=33560227 https://news.ycombinator.com/item?id=33560227
- s9w 4y ago
  [dead]
- zik 4y ago
  > It's not memory safe Modern C++ has made big inroads into removing memory safety issues though. Memory safety bugs are relatively uncommon in modern C++ compared to pre C++11 times. You could argue that C++ is still "unsafe by default" and you'd be right. But most C++ programmers use smart pointers and unique pointers rather than raw pointers now, vectors instead of raw arrays, etc.. And it does make a big difference.
  - TazeTSchnitzel 4y ago
    Aren't vectors just as vulnerable to out-of-bounds access as any C-like array? Most C++ additions have plenty of undefined behaviour.
    - 4y ago
xiaq 4y ago
Your definition of "replace" is too strict: the idea of a successor language is not replacing all existing code, but rather making it possible for individual projects to painlessly evolve from the old language to a new one. Some old code - whether entire inactive projects or inactive parts of active projects - may never get rewritten in the new language and that is OK.
- hot_gril 4y ago
  "Replace" ought to at least mean, new projects don't use the old thing.
mikebenfield 4y ago
> And C++ just... doesn't have that many real problems. I can honestly say I've never known anyone who has written a lot of code in both C++ and some other language who has this opinion. I'd say, to the contrary, that almost every feature and characteristic of C++ is a problem - it's either a complete disaster in terms of programmer ergonomics or it makes it way too easy to create terrible bugs. It's _all_ wrong.
- opportune 4y ago
  I have this opinion. I much prefer C++ to Go and Rust. There need to be languages that don’t hold your hand - you can argue instead that C++ is an incorrect language choice for many projects and I’d agree with you though Once you understand lifetimes well C++ is a joy to write. 99% of all the complaints about C++ are 1. lack of automatic bounds checking, which is trivial to implement yourself 2. memory management problems because people have a poor mental model of how it works, which can be learned.
  - Ygg2 4y ago
    > Once you understand lifetimes well C++ is a joy to write. Well, so is Rust. You even have usable macros and templates that are't cancer to write.
  - LeFantome 4y ago
    You did not claim that C++ had no problems, just that you prefer it. No fight from me. You should be able to like what you want. While not a shot at your choice, a C++ dev that I follow a bit is the creator of SerenityOS. Many times and in many of his YouTube videos he has sung the praises of C++ and called it his favourite language. Presently, he is writing his own language, Jakt, to replace it. I find that interesting.
  - colinsane 4y ago
    > 99% of all the complaints about C++ are … 2. memory management problems because people have a poor mental model of how it works, which can be learned. or memory management problems because Qt uses a different string type than glib uses a different string type than std, each with different ownership semantics, and by the way some of these claim to be thread-safe while others don’t say clearly one way or the other in the docs, except actually Qt’s copy-on-write implementation claims to be thread safe but assumes that the compiler inlines the mutation operators so if you forward-declare `struct QString` instead of #include <QString> then the operations might not be thread-safe… i think the CoW problem might have been with Qt’s set type, not its string type, but you get the idea. it’s not just the language: it’s the library ecosystem too. it’s that any time i dive into contributing to a new C++ project i have to learn potentially a new memory model, one which is likely assumed instead of documented. RAII presented an opportunity to normalize all this stuff; i’m not sure how significantly it’s unified things: i suspect it’s effective primarily in greenfield projects.
keyle 4y ago
I'm with you but you lost me at the car analogy. Be careful with that, because it only takes government to decide to heavily tax something or simply phase out something for it to go away. Eventually the minority cost rises so it becomes a self full-filling prophecy. That, will not apply to C++ or languages in general.
- TheRealPomax 4y ago
  I will not be careful with that at all because I didn't restrict my statement to "some country". I said cars, full stop, you're trying to replace cars on a planetary scale driving (a non-trivial part of) the economy of the entire planet, just as C++ is used on a planetary scale, driving (a non-trivial part of) the economy of the entire planet. Could countries that currently don't really have cars? Yeah, probably. In the same way that a market segment that doensn't use C++ can decide not to use C++. Could a country like Vietnam? Doubtful, but maybe. A market segment with low C++ penetration can probably decide they want to collectively move away from C++. Could China? Not anymore, no. C++ drives too much software in the market segment to make sense to replace, even if the grass is greener on the other side of the language fence. Could the US or the EU ban cars (and again: not ICEs, but cars, full stop)? Let's all try not to laugh.
permo-w 4y ago
no language is ever going to be 100% replaced, but C++ has largely replaced C and Swift will likely largely replace Objective-C. this article obviously isn’t discussing whether something will wipe C++ off the face of the earth but that it might replace most of its use cases. why are you nitpicking over the word replace?
- LeFantome 4y ago
  Languages do get replaced. It is just taking them longer and longer. How much ALGOL do you see out there? There will be almost no Objective C at some point. There will be almost no Visual Basic.NET at some point. A C++ replacement may take longer than the rest of my life. It is possible though that we may not be that many years away that, for new projects, it may be uncommon to choose an “unsafe” language.
MBCook 4y ago
> Swift didn't replace Objective C Give it time. Unlike the other examples one company (Apple) has full control here. There is basically zero demand for Objective-C outside of development for Apple platforms. Apple is already making Swift only features and APIs and is deprecating older things. Obj-C is arguably legacy already, but still works fine. I’ll bet plenty of money there will find a day when Apple says “This is it, next release it’s out of the toolchain”. Existing developers often have Obj-C code (I do), but the biggest user is Apple. So they can’t kill it tomorrow. But its days are numbered. No one is in that kind of position with C/C++/JS/Java.
- pjmlp 4y ago
  One exception is Metal, it is actually implemented in Objective-C with Swift bindings.
nielsbot 4y ago
I'd argue Swift has replaced Objective-C, for new code. Or will soon. If Carbon does the same vis-a-vis C++, I'd say they've succeeded in "replacing C++".
- pjmlp 4y ago
  Only because the platform's own says it is my way or the highway, Carbon authors don't have this leverage. Just like Kotlin hardly matters outside Android.
  - nielsbot 4y ago
    You are still free to use Obj-C for new projects... for now.
rf15 4y ago
Worse still in this enumeration, TypeScript isn't a replacement like the others at all: no major js platform (browsers, nodejs) supports it. (here the term "native support" is thrown around a lot, but I feel at this point you're already well in llvm territory with the definition of "support")

hulitu 4y ago

> or C lead to C++, As "Unix haters handbook" says: C++ is to C, what lung cancer is to lung.

TheRealPomax 4y ago
A profoundly idiotic statement, but on-brand for that manifesto.
RcouF1uZ4gsC 4y ago
> As "Unix haters handbook" says As they compile their C code using a compiler written in C++. (GCC and Clang are both written in C++).
- jcranmer 4y ago
  To be fair, that wasn't true when the Unix haters handbook was written, almost 30 years ago.
  - pjmlp 4y ago
    Nonetheless it was true that C++, C and UNIX share the same birthplace.
guestbest 4y ago
If a language helps a developer create a solution, it is fundamentally not a cancer.
pjmlp 4y ago
I love how it ignores that C++ was developed on the same place, even on the same corridor as C and UNIX devs used to work.
- __d 4y ago
  And yet ... the C developers were never impressed by C++, and (for instance) Plan9 ended using a differently enhanced version of C, and never (I think?) had a C++ compiler.
  - pjmlp 4y ago
    The same developers that came up with Limbo and Go, somehow there is a common trend on how they see language design and the alternatives.
    - jokethrowaway 4y ago
      YMMV but Go is one of the most divisive tech out there for me. I like C++ and Rust. If I meet a dev who likes Go, I can guarantee we won't agree on much.

JustBreath 4y ago

Betteridge's law holds up as usual.

TheRealPomax 4y ago
It'd be quite nice if HN automatically flagged that to submitters. "Please rewrite this title to describe the article, as it is currently a question and the answer is no".

pizza234 4y ago

> And C++ just... doesn't have that many real problems. From Carbon's README: > C++ [...] is struggling to improve and meet developers' needs, as outlined above, in no small part due to accumulating decades of technical debt. Incrementally improving C++ is extremely difficult, both due to the technical debt itself and challenges with its evolution process. The best way to address these problems is to avoid inheriting the legacy of C or C++ directly, and instead start with solid language foundations like modern generics system, modular code organization, and consistent, simple syntax.

TinkersW 4y ago
None of those are 'issues' for me. The language isn't perfect but the Carbon approach seems to not solve any meaningful issues.
- deleted 4y ago
  [deleted]
dralley 4y ago
The question is not whether C++ has issues, it's whether the rest of the ecosystem cares about them as much as the Carbon devs, enough so that they would adopt Carbon instead of C++. Carbon will face the same issue as Dlang. Everyone agrees that Dlang is an improvement over C++ in many significant aspects, and a very impressive one at that, but in order to gain meaningful adoption the benefit has to be high enough to justify the pain of swimming upstream against the rest of the ecosystem. D never quite made it above that threshold, though perhaps in an alternate history where Google picked it up instead of pushing Go, it could have.
- pornel 4y ago
  D has two problems: 1. Being "C++ but nicer" is an awkward niche. It's not differentiated enough to overcome switching costs for C++ users. It's hard to justify risks of a new language, costs of hiring and/or code rewrites just for quality of life improvements. At the same time being similar to C++ is a turn off for users who don't like C++ and look for something different. 2. D with a GC is not really competing with C++ in its core niche where C++ is irreplaceable, but rather with many many other GC languages for programs that can use almost any language. The idea of GC being optional is a hard sell, because it's an obvious switcheroo — without the GC you don't get all of the nice features, so GC-less D is even less differentiated from C++. Carbon at least avoids the second problem. I'm not sure if Carbon's new syntax and semantic tweaks are different enough.

IshKebab 4y ago

Your threshold for "replace" is too high. Did cars not replace horses because horses still exist?

kalcode 4y ago

> So based on the article's own observation: no, of course not. This had very little to the discussion. Of course it can't be replaced. Code is created by humans, and as long as we have opinions nothing gets truly replaced. Just decreased usage over time. > C++ and Switft just became "more dominant". Yup, like this. Of course a general statement is no. I have very little interest in this topic. But I seen this SAME comment a million times on anything thats new that attempts to challenge something. And as usual whether something "dethrones" something is less interesting than what changes or ideas that it offers. Just like ALL those you listed, they didn't replace any of those, but they definitely challenged the ecosystems, or improved the old ones. Naunce discussion is far more interesting. For example, why do you think Carbon won't be able to gain dominance over time? I mean I think thats a huge hurdle too.

TheRealPomax 4y ago
You've apparently read the reverse of what I said. I said the new thing didn't replace the old thing, and that therefore the idea that "we are doing the same, and it will replace the old thing" is nonsense. I did not say that because it can't replace it, it is therefore not worth doing. It absolutely is, like all attempts at making things that "solve the problems that C++ has" have been varying degrees of worth it. But the idea that it can, let alone will, replace the original is such an obvious "no" that the title is clickbait. Or slide-bait (since it was originally a conf. talk)

throwaway894345 4y ago

Of course, I agree that C++ isn't going to entirely disappear, but I don't understand what you mean by "C++ doesn't have many real problems, only irks". Surely the lack of memory safety is more than a mere irk--certainly Mozilla felt strongly enough to develop an entirely new programming language (as did Carbon's developers), and of course entire domains have moved away from C++ entirely (often in favor of GC languages). Yes, there remains some contingent of people for whom things like "deterministic memory management" or "immaturity for $domain" are bigger problems than those presented by C++, but that doesn't mean that C++ is without real problems, right?

jameswryan 4y ago

> And C++ just... doesn't have that many real problems. 70% of security bugs are memory safety issues. That's a lot of real problems. > It has a lot of irks, but the problems people run into are problems that others already solved, a thousand times, over the last half century, in many different ways for many different iterations of the language. People run into memory safety issues more often in new C++ code. https://www.chromium.org/Home/chromium-security/memory-safety/ https://www.chromium.org/Home/chromium-security/memory-safet... https://security.googleblog.com/2021/09/an-update-on-memory-safety-in-chrome.html https://security.googleblog.com/2021/09/an-update-on-memory-... https://github.com/microsoft/MSRC-Security-Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf https://github.com/microsoft/MSRC-Security-Research/blob/mas... https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI... https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20presentations/Adam%20Zabrocki%20%20%20Alex%20Tereshkin%20-%20Exploitation%20in%20the%20era%20of%20formal%20verification%20a%20peek%20at%20a%20new%20frontier%20with%20AdaCore-SPARK.pdf https://media.defcon.org/DEF%20CON%2030/DEF%20CON%2030%20pre... https://advocacy.consumerreports.org/research/report-future-of-memory-safety/ https://advocacy.consumerreports.org/research/report-future-... https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/ https://alexgaynor.net/2020/may/27/science-on-memory-unsafet... https://github.com/google/sanitizers/blob/master/hwaddress-sanitizer/MTE-iSecCon-2018.pdf https://github.com/google/sanitizers/blob/master/hwaddress-s... https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html https://security.googleblog.com/2022/12/memory-safe-language...

dxhdr 4y ago
> 70% of security bugs are memory safety issues. That's a lot of real problems. Run your code in a WASM sandbox or on a GPU, problem solved.
- adgjlsfhk1 4y ago
  "Run your code in a WASM sandbox" and then your C++ is way slower (and speed is the only reason you were using C++ in the first place)

credit_guy 4y ago

> And C++ just... doesn't have that many real problems. It does not have many, but it has one and it's big. It's not memory safe. Check out this talk by Herb Sutter, around minute 43: This is the first time a government [see note] has actually issued guidance to industry broadly that was the barest paraphrase away from "where possible don't use C and C++" [ Note: in this context, the "government" is the US Department of Commerce and NIST, which, according to Herb, have issued a detailed guidance in response to the Executive Order on Cybersecurity [2]. While I couldn't find that guidance, I found one by the NSA [3], which saw quite a few comments here on HN in December last year [4] ]. [1] https://www.youtube.com/watch?v=ELeZAKCN4tY https://www.youtube.com/watch?v=ELeZAKCN4tY [2] https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/ https://www.whitehouse.gov/briefing-room/presidential-action... [3] https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI... [4] https://news.ycombinator.com/item?id=33560227 https://news.ycombinator.com/item?id=33560227

s9w 4y ago
[dead]
zik 4y ago
> It's not memory safe Modern C++ has made big inroads into removing memory safety issues though. Memory safety bugs are relatively uncommon in modern C++ compared to pre C++11 times. You could argue that C++ is still "unsafe by default" and you'd be right. But most C++ programmers use smart pointers and unique pointers rather than raw pointers now, vectors instead of raw arrays, etc.. And it does make a big difference.
- TazeTSchnitzel 4y ago
  Aren't vectors just as vulnerable to out-of-bounds access as any C-like array? Most C++ additions have plenty of undefined behaviour.
  - 4y ago

xiaq 4y ago

Your definition of "replace" is too strict: the idea of a successor language is not replacing all existing code, but rather making it possible for individual projects to painlessly evolve from the old language to a new one. Some old code - whether entire inactive projects or inactive parts of active projects - may never get rewritten in the new language and that is OK.

hot_gril 4y ago
"Replace" ought to at least mean, new projects don't use the old thing.

mikebenfield 4y ago

> And C++ just... doesn't have that many real problems. I can honestly say I've never known anyone who has written a lot of code in both C++ and some other language who has this opinion. I'd say, to the contrary, that almost every feature and characteristic of C++ is a problem - it's either a complete disaster in terms of programmer ergonomics or it makes it way too easy to create terrible bugs. It's _all_ wrong.

opportune 4y ago
I have this opinion. I much prefer C++ to Go and Rust. There need to be languages that don’t hold your hand - you can argue instead that C++ is an incorrect language choice for many projects and I’d agree with you though Once you understand lifetimes well C++ is a joy to write. 99% of all the complaints about C++ are 1. lack of automatic bounds checking, which is trivial to implement yourself 2. memory management problems because people have a poor mental model of how it works, which can be learned.
- Ygg2 4y ago
  > Once you understand lifetimes well C++ is a joy to write. Well, so is Rust. You even have usable macros and templates that are't cancer to write.
- LeFantome 4y ago
  You did not claim that C++ had no problems, just that you prefer it. No fight from me. You should be able to like what you want. While not a shot at your choice, a C++ dev that I follow a bit is the creator of SerenityOS. Many times and in many of his YouTube videos he has sung the praises of C++ and called it his favourite language. Presently, he is writing his own language, Jakt, to replace it. I find that interesting.
- colinsane 4y ago
  > 99% of all the complaints about C++ are … 2. memory management problems because people have a poor mental model of how it works, which can be learned. or memory management problems because Qt uses a different string type than glib uses a different string type than std, each with different ownership semantics, and by the way some of these claim to be thread-safe while others don’t say clearly one way or the other in the docs, except actually Qt’s copy-on-write implementation claims to be thread safe but assumes that the compiler inlines the mutation operators so if you forward-declare `struct QString` instead of #include <QString> then the operations might not be thread-safe… i think the CoW problem might have been with Qt’s set type, not its string type, but you get the idea. it’s not just the language: it’s the library ecosystem too. it’s that any time i dive into contributing to a new C++ project i have to learn potentially a new memory model, one which is likely assumed instead of documented. RAII presented an opportunity to normalize all this stuff; i’m not sure how significantly it’s unified things: i suspect it’s effective primarily in greenfield projects.

keyle 4y ago

I'm with you but you lost me at the car analogy. Be careful with that, because it only takes government to decide to heavily tax something or simply phase out something for it to go away. Eventually the minority cost rises so it becomes a self full-filling prophecy. That, will not apply to C++ or languages in general.

TheRealPomax 4y ago
I will not be careful with that at all because I didn't restrict my statement to "some country". I said cars, full stop, you're trying to replace cars on a planetary scale driving (a non-trivial part of) the economy of the entire planet, just as C++ is used on a planetary scale, driving (a non-trivial part of) the economy of the entire planet. Could countries that currently don't really have cars? Yeah, probably. In the same way that a market segment that doensn't use C++ can decide not to use C++. Could a country like Vietnam? Doubtful, but maybe. A market segment with low C++ penetration can probably decide they want to collectively move away from C++. Could China? Not anymore, no. C++ drives too much software in the market segment to make sense to replace, even if the grass is greener on the other side of the language fence. Could the US or the EU ban cars (and again: not ICEs, but cars, full stop)? Let's all try not to laugh.

permo-w 4y ago

no language is ever going to be 100% replaced, but C++ has largely replaced C and Swift will likely largely replace Objective-C. this article obviously isn’t discussing whether something will wipe C++ off the face of the earth but that it might replace most of its use cases. why are you nitpicking over the word replace?

LeFantome 4y ago
Languages do get replaced. It is just taking them longer and longer. How much ALGOL do you see out there? There will be almost no Objective C at some point. There will be almost no Visual Basic.NET at some point. A C++ replacement may take longer than the rest of my life. It is possible though that we may not be that many years away that, for new projects, it may be uncommon to choose an “unsafe” language.

MBCook 4y ago

> Swift didn't replace Objective C Give it time. Unlike the other examples one company (Apple) has full control here. There is basically zero demand for Objective-C outside of development for Apple platforms. Apple is already making Swift only features and APIs and is deprecating older things. Obj-C is arguably legacy already, but still works fine. I’ll bet plenty of money there will find a day when Apple says “This is it, next release it’s out of the toolchain”. Existing developers often have Obj-C code (I do), but the biggest user is Apple. So they can’t kill it tomorrow. But its days are numbered. No one is in that kind of position with C/C++/JS/Java.

pjmlp 4y ago
One exception is Metal, it is actually implemented in Objective-C with Swift bindings.

nielsbot 4y ago

I'd argue Swift has replaced Objective-C, for new code. Or will soon. If Carbon does the same vis-a-vis C++, I'd say they've succeeded in "replacing C++".

pjmlp 4y ago
Only because the platform's own says it is my way or the highway, Carbon authors don't have this leverage. Just like Kotlin hardly matters outside Android.
- nielsbot 4y ago
  You are still free to use Obj-C for new projects... for now.

rf15 4y ago

Worse still in this enumeration, TypeScript isn't a replacement like the others at all: no major js platform (browsers, nodejs) supports it. (here the term "native support" is thrown around a lot, but I feel at this point you're already well in llvm territory with the definition of "support")