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.
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.
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?
(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?
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.)
As soon as you disable the GC in D, you end up with a really awkward to use language, no closures, no exceptions, no dynamic arrays, I think you can't even use the common string in D without the GC.
People arguing that D can be used without a GC are just trying to sell you on something.
There is a flag to allocate them with malloc, and use RC.
> no dynamic arrays, I think you can't even use the common string in D without the GC.
Totally not true. You can't concatenate arrays (string are just arrays of char) with `arr1 ~ arr2` and you can't `new` them, but you can do pretty much anything else.
> People arguing that D can be used without a GC are just trying to sell you on something.
Of course, but C++ people have an unnatural aversion to GC also the D GC only ever collects if you allocate from it. No allocations == no collections.
For the most part, GC is a productivity enhancer, you can roll your own allocators, use malloc, etc. if you need to. You can statically ensure that some or all of your code doesn't use the GC and as expected there is a productivity/code maintenance price you pay for doing so.
If anything, D should stop pretending that it doesn't have a GC and stop trying to appeal to people who don't want a GC, it's a losing battle. D should just accept the fact that it is a GC'd language and start making the argument for why it's a better GC'd language than Java or C# or the host of other GC'd languages.
The vast majority of C++ developers do not want a GC'd version of C++, but it's possible that Java developers could be interested in a C++-like language that has a GC and good C compatibility.
GC is just one of the styles.
Yes, if you use "new" you get a GC allocation. But nobody makes you use "new". If you use the array concatenation operator, it uses the GC. But there are many ways to concatenate an array that don't use it.
As for closures, they get allocated on the GC only if they escape the stack frame. This is detected, and if you want to be told about it, annotate the function with @nogc.
What is that flag? Do you have a link to the documentation? I do remember talk about adding a feature that would allow exceptions to be allocated in @nogc code, but that was never ultimately implemented and looks to be postponed (to the best of my knowledge).
D is free to use for any purpose, being Boost licensed. We don't even keep track of who downloads it. Not that such info would do any good anyway, as anyone can host the distributions for download.
So yes, you can secretly use D at work, and we won't be able to tell on you!
To me optional GC is a major downside. Because the option to use the GC exists, I don't believe that the language and the library ecosystem will have first-class support for the no-GC users. For example, DUB's website doesn't have an option to search only for no-GC packages. I don't want to be restricted to the worse half of the language.
Doing everything that C++ can do is not a reason to switch away from C++. C++ can already do everything that C++ can do.
D has some nicer syntax, and neat little features like universal function/method call syntax, unittest blocks. But I can't go to my boss and say "Hey, we should rewrite our product in D. Why? Because the unittest block is a really cool idea".
Indeed, you should not change languages based on only one thing. It's also pedantically true that one can do anything in any Turing-complete language.
A much more interesting point is how productive one can be in different languages.
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.
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.
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.
I'm waiting for some other shoes to drop here. There's some fine print in this promise that isn't widely grokked yet.
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.
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.
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.