Hacker News Reader

Comment by dralley | Hacker News Reader

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.

View on HN

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.

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.

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?

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?

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.

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.)

As much as people want to claim that you don't need to use the GC with D, in reality D is a garbage collected language and you do need to use a GC if you want to use D.

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.

> no exceptions

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.

You can absolutely argue the benefits of a GC, and there are plenty of GC'd languages that as you say are great productivity enhancers.

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.

D is not a xxxx language. It enables programming in many diverse styles, styles that some languages are totally dedicated to (like Haskell is to functional programming).

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.

You are absolutely right. GC can be an advantage and there is no need to be ashamed of it. Herb Sutter is working on "syntax 2" for the C++ language and wants to have GC smart pointers in C++. The D creators should work on improving the GC so that it does not force pauses instead of explaining that GC does not have to be used.

>There is a flag to allocate them with malloc, and use RC.

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).

> to sell you

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!

I don't know if you've noticed my previous comment already said D's GC is optional?

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".

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

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.

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.

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.

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

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.

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.

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.

Google's is mostly happy with C++17, as per their guidelines.

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.

Reply on news.ycombinator.com