Why I Like D

[Ola Fosheim Grøstad]

On Wednesday, 12 January 2022 at 20:48:39 UTC, forkit wrote:
> Fear of GC is just a catch-all-phrase that serves no real 
> purpose, and provides no real insight into what programmers are 
> thinking.

"Fear of GC" is just a recurring _excuse_ for not fixing the most 
outdated aspects of the language/compiler/runtime.

I have no fear of GC, I've used GC languages since forever, but I 
would never want a GC in the context of system level or real time 
programming. I also don't want to deal with mixing mostly 
incompatible memory management schemes in an application 
dominated by system level programming.

In this context a GC should be something local, e.g. you might 
want to use a GC for a specific graph or scripting language in 
your application.

Do I want a GC/ARC for most of my high level programming? Hell 
yes! But not for system level programming, ever.

(Walter has always positioned D as a system level language and it 
should be judged as such.  Maybe D isn't a system level language, 
but then the vision should be changed accordingly.)


> It's all about autonomy and self-government (on the decision of 
> whether to use GC or not, or when to use it, and when not to 
> use it.

Which essentially is the essence of system level programming. You 
adapt the language usage to the hardware/use context, not the 
other way around.

You shouldn't be glued to nonsensical defaults that you have to 
disable. You should  have access to building blocks that you can 
compose to suit the domain you are working with.

A GC can be one such building block, and in fact, the C++ 
community does provide several GCs as building blocks, but there 
is no force feeding… Which is why C++ is viewed as a hard core 
system level language by everyone and D isn't.


> I don't believe people are attracted to D because it has GC. 
> There are better languages, and better supported languages, 
> with GC.

Or more importantly; low latency GCs and a language designed for 
it!


> Also, the idea that 'GC' means you never have to think about 
> memory management... is just a ridiculous statement..

I don't have to think much about memory management in Python, 
JavaScript or Go, but I would also never do anything close to 
system level programming in those languages.

You can create very interesting interactive applications in 
JavaScript, but then you:

1. Rely on clever system level programming in a very heavy 
browser runtime.


2. Use an eco system for interactive applications that is 
designed around the specific performance characteristics of the 
javascript runtime.

3. Adapt the application design to the limitations of the browser 
platform.

4. Get to use a much better low latency GC.

Point 1, 2 and 3 are not acceptable for a system level language… 
So that is a different situation. And D does not provide 4, so 
again, a different situation.

Cheers!