7 ms·

> 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 abo

> 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.
  - WalterBright 4y ago
    D's GC is optional. You don't have to use it. You don't get all the D features without the GC, but you do get everything that C++ can do. One unnoticed feature of D's GC is it enables safe memory allocation when doing CTFE (Compile Time Function Execution). This can be used even when the code being compiled for runtime does not link in the GC. It greatly increases the power of CTFE.
    - ninkendo 4y ago
      Can I disable GC on code which was written with the assumption that GC is enabled? (Honest question... I've never used D but I've heard about the GC being optional before, and I'm skeptical.) That is to say, if I want to use a third-party library, and that library was written to use the GC, and I want to _not_ use the GC, can I use said library? Or does using it require that I enable the GC for my code as well?
      - WalterBright 4y ago
        You can disable collections being run, but if the library uses the GC, then it uses the GC! (Lots of D users use a mix of GC and explicit allocation. Each has their best use cases.) May I ask what your concern is?
        danbolt 4y ago
        I can’t speak for the parent, but I know there are programs that avoid garbage collection due to pauses affecting the business logic. I think developers in those situations often look to C, C++, or Rust as any particular library you reach for isn’t going to be introducing GC into your program.
        WalterBright 4y ago
        The D's GC collection cycle does pause, but it does not run unless the GC is asked to do an allocation. Hence, if you don't do GC allocations, or at least do not do them in your realtime loop, it will not pause. D is not a GC language. It's a language with an optional GC. (It also does not have the code gen compromises that fully GC languages rely on, such as write gates.)
- duped 4y ago
  Anecdotally I think the answer is "yes!!!" A little over a decade ago the industry (of people that cared about C++) were psyched about C++11. Today people don't really give a crap about C++20 other than checking that their code still compiles and people barely know what's in C++23. The air has been let out of the balloon, since other ecosystems have grown up and are easier/better to use than C++. I know of multiple shops that would have "never" moved off C++ that have switched to C# or Go. The performance is there and the headaches aren't. And frankly, C++ doesn't have an ecosystem. There's boost, abseil, folly, and to an extent Qt. Everything else is C and wrappers around C. Moving off C++ means adopting a language with a good standard library and/or an actual ecosystem that does useful things - which C++ massively lacks. Rust is definitely in the wings and growing, it's just a shame that so much of the industrial use turned out to be crypto. Once C++ developers get over their irrational fear of generic programming and package management, Rust and it's ecosystem become extremely compelling.
  - humanrebar 4y ago
    The fact that Rust has an ecosystem kind of hobbles it. C and C++ are often used in basically all the other ecosystems because that's what they are for. C and C++ don't have a fear of package management. On the contrary, they're packaged in more ecosystems than probably anything else: gems, wheels, rpms, debs, nix, conan, vcpkg, you name it. The hard part of C and C++ packaging is making it easy for projects to integrate in all those ecosystems. If carbon goes the same route as Rust, Go, etc. by standing up yet another hermetic ecosystem, it will be very clear that it's not really trying to replace C and C++; it will merely be trying to carve out a new niche.
  - pjmlp 4y ago
    I am convinced that had Java and C# been Delphi like in, a RAD environment AOT compiled by default, with the performance focus that only now they are having due to Go and such, and probably not even C++11 would have mattered that much.
- ninkendo 4y ago
  > Carbon will face the same issue as Dlang I think one thing that Carbon has going for it is that it's bidirectionally compatible with C++, in the same way that Kotlin is with Java (or Swift with ObjC). If you have a massive C++ codebase, you're supposed to be able to just add new Carbon code, without changing any of your existing codebase. This should allow gradual adoption at whatever pace you want, which should help adoption a lot.
  - humanrebar 4y ago
    Is it? Can you replace C++23 code with Carbon? Will it work with C++ modules? Will the existing find_package calls in downstream C++ CMake projects work? I'm waiting for some other shoes to drop here. There's some fine print in this promise that isn't widely grokked yet.
    - laurentlb 4y ago
      It should have enough compatibility with C++ that Google and others will be able to incrementally migrate their C++ code. So C++ modules should be supported. Code migration is part of the Carbon language requirements. Carbon is being designed because other existing langages didn't focus on this aspect. The specific details and edge cases are probably to be determined.
      - humanrebar 4y ago
        It's fine to have a goal for general purpose compatibility with C++, though that's harder than it sounds. More than likely there will have to be lines drawn in the sand like "no ABI compatibility ever" or "assumes you're using only clang toolchains" which will necessarily limit how generally adoptable the language is. It's clear that compatibility is a goal but it's clearly not a feature yet, so we should be careful to talk about carbon as if it has that feature, especially given how hard that feature will be to implement and support. I'm more confident that Google will be able to meaningfully use carbon in its monorepo than I am that it will be a good replacement for C and C++ for any given non-Google project.
      - 4y ago
- zackees 4y ago
  Carbon will likely help C++ because now there is a new playground to iterate on new ideas and then when they stabilize then C++ can decide to just copy it.
ActorNightly 4y ago
The problem is that people take for granted that [insert code organization method here] is good and lack of it in another language is bad. This is a rehash of the conversation between Java and C++ proponents about the correct way to do multiple inheritance. In practice, none of this really matters. For example, generics are just one way to do code organization, you can write codebases that are clear, maintainable, and reliable, without ever touching generics once.

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.
- WalterBright 4y ago
  D's GC is optional. You don't have to use it. You don't get all the D features without the GC, but you do get everything that C++ can do. One unnoticed feature of D's GC is it enables safe memory allocation when doing CTFE (Compile Time Function Execution). This can be used even when the code being compiled for runtime does not link in the GC. It greatly increases the power of CTFE.
  - ninkendo 4y ago
    Can I disable GC on code which was written with the assumption that GC is enabled? (Honest question... I've never used D but I've heard about the GC being optional before, and I'm skeptical.) That is to say, if I want to use a third-party library, and that library was written to use the GC, and I want to _not_ use the GC, can I use said library? Or does using it require that I enable the GC for my code as well?
    - WalterBright 4y ago
      You can disable collections being run, but if the library uses the GC, then it uses the GC! (Lots of D users use a mix of GC and explicit allocation. Each has their best use cases.) May I ask what your concern is?
      - danbolt 4y ago
        I can’t speak for the parent, but I know there are programs that avoid garbage collection due to pauses affecting the business logic. I think developers in those situations often look to C, C++, or Rust as any particular library you reach for isn’t going to be introducing GC into your program.
        WalterBright 4y ago
        The D's GC collection cycle does pause, but it does not run unless the GC is asked to do an allocation. Hence, if you don't do GC allocations, or at least do not do them in your realtime loop, it will not pause. D is not a GC language. It's a language with an optional GC. (It also does not have the code gen compromises that fully GC languages rely on, such as write gates.)
duped 4y ago
Anecdotally I think the answer is "yes!!!" A little over a decade ago the industry (of people that cared about C++) were psyched about C++11. Today people don't really give a crap about C++20 other than checking that their code still compiles and people barely know what's in C++23. The air has been let out of the balloon, since other ecosystems have grown up and are easier/better to use than C++. I know of multiple shops that would have "never" moved off C++ that have switched to C# or Go. The performance is there and the headaches aren't. And frankly, C++ doesn't have an ecosystem. There's boost, abseil, folly, and to an extent Qt. Everything else is C and wrappers around C. Moving off C++ means adopting a language with a good standard library and/or an actual ecosystem that does useful things - which C++ massively lacks. Rust is definitely in the wings and growing, it's just a shame that so much of the industrial use turned out to be crypto. Once C++ developers get over their irrational fear of generic programming and package management, Rust and it's ecosystem become extremely compelling.
- humanrebar 4y ago
  The fact that Rust has an ecosystem kind of hobbles it. C and C++ are often used in basically all the other ecosystems because that's what they are for. C and C++ don't have a fear of package management. On the contrary, they're packaged in more ecosystems than probably anything else: gems, wheels, rpms, debs, nix, conan, vcpkg, you name it. The hard part of C and C++ packaging is making it easy for projects to integrate in all those ecosystems. If carbon goes the same route as Rust, Go, etc. by standing up yet another hermetic ecosystem, it will be very clear that it's not really trying to replace C and C++; it will merely be trying to carve out a new niche.
- pjmlp 4y ago
  I am convinced that had Java and C# been Delphi like in, a RAD environment AOT compiled by default, with the performance focus that only now they are having due to Go and such, and probably not even C++11 would have mattered that much.
ninkendo 4y ago
> Carbon will face the same issue as Dlang I think one thing that Carbon has going for it is that it's bidirectionally compatible with C++, in the same way that Kotlin is with Java (or Swift with ObjC). If you have a massive C++ codebase, you're supposed to be able to just add new Carbon code, without changing any of your existing codebase. This should allow gradual adoption at whatever pace you want, which should help adoption a lot.
- humanrebar 4y ago
  Is it? Can you replace C++23 code with Carbon? Will it work with C++ modules? Will the existing find_package calls in downstream C++ CMake projects work? I'm waiting for some other shoes to drop here. There's some fine print in this promise that isn't widely grokked yet.
  - laurentlb 4y ago
    It should have enough compatibility with C++ that Google and others will be able to incrementally migrate their C++ code. So C++ modules should be supported. Code migration is part of the Carbon language requirements. Carbon is being designed because other existing langages didn't focus on this aspect. The specific details and edge cases are probably to be determined.
    - humanrebar 4y ago
      It's fine to have a goal for general purpose compatibility with C++, though that's harder than it sounds. More than likely there will have to be lines drawn in the sand like "no ABI compatibility ever" or "assumes you're using only clang toolchains" which will necessarily limit how generally adoptable the language is. It's clear that compatibility is a goal but it's clearly not a feature yet, so we should be careful to talk about carbon as if it has that feature, especially given how hard that feature will be to implement and support. I'm more confident that Google will be able to meaningfully use carbon in its monorepo than I am that it will be a good replacement for C and C++ for any given non-Google project.
    - 4y ago
zackees 4y ago
Carbon will likely help C++ because now there is a new playground to iterate on new ideas and then when they stabilize then C++ can decide to just copy it.

ActorNightly 4y ago

The problem is that people take for granted that [insert code organization method here] is good and lack of it in another language is bad. This is a rehash of the conversation between Java and C++ proponents about the correct way to do multiple inheritance. In practice, none of this really matters. For example, generics are just one way to do code organization, you can write codebases that are clear, maintainable, and reliable, without ever touching generics once.