Comment by pornel | Hacker News Reader

Comment by pornel | Hacker News Reader

Parent Full thread

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.

Reply on news.ycombinator.com