Why I Like D

[H. S. Teoh]

On Fri, Jan 14, 2022 at 01:19:01AM +0000, forkit via Digitalmars-d-announce wrote:
[...]
> C provides even greater autonomy over both C++ and D. And I'd argue,
> that's why C remains so useful, and so popular (for those problems
> where such a level of autonomy is needed).
> 
> By, 'autonomy', I mean a language provided means, for choosing what
> code can do, and how it does it.
[...]
> An aversion to losing that autonomy, I believe, is a very real reason
> as to why larger numbers of C++ programmers do not even consider
> switching to D.

How is using D "losing autonomy"?  Unlike Java, D does not force you to
use anything. You can write all-out GC code, you can write @nogc code
(slap it on main() and your entire program will be guaranteed to be
GC-free -- statically verified by the compiler). You can write
functional-style code, and, thanks to metaprogramming, you can even use
more obscure paradigms like declarative programming.

If anything, D makes it *easier* to have "autonomy", because its
metaprogramming capabilities let you do so without contorting syntax or
writing unmaintainable write-only code.  I can theoretically do
everything in C++ that I do in D, for example, but C++ requires that I
spend 5x the amount of effort to navigate its minefield of language
gotchas (and then 50x the effort to debug the resulting mess), and
afterwards I have to visit the optometrist due to staring at unreadable
syntax for extended periods of time.

In D, I get to choose how low-level I want to go -- if all I need is a
one-off shell script substitute, I can just allocate away and the GC
will worry about cleaning after me.  If I need to squeeze out more
performance, I run the profiler and identify GC hotspots and fix them
(or discover that the GC doesn't even affect performance, and redirect
my efforts elsewhere, where it actually matters more).  If that's not
enough, GC.disable and GC.collect lets me control how the GC behaves.
If that's still not enough, I slap @nogc on my inner loops and pull out
malloc/free.

In C++, I'm guaranteed that there is no GC -- even when having a GC
might actually help me achieve what I want.  In order to reap the
benefits of a GC in C++, I have to jump through *tons* of hoops --
install a 3rd party GC, carefully read the docs to avoid doing things
that might break it ('cos it's not language-supported), be excluded from
using 3rd party libraries that are not compatible with the GC, etc..
Definitely NOT worth the effort for one-off shell script replacements.
It takes 10x the effort to write a shell-script substitute in C++
because at every turn the language works against me -- I can't avoid
dealing with memory management issues at every turn -- should I use
malloc/free and fix leaks / dangling pointers myself? Should I use
std::autoptr? Should I use std::shared_ptr? Write my own refcounted
pointer for the 15th time?  Half my APIs would be cluttered with memory
management paraphrenalia, and half my mental energy would be spent
fiddling with pointers instead of MAKING PROGRESS IN MY PROBLEM DOMAIN.

With D, I can work at the high level and solve my problem long before I
even finish writing the same code in C++.  And when I need to dig under
the hood, D doesn't stop me -- it's perfectly fine with malloc/free and
other such alternatives.  Even if I can't use parts of Phobos because of
GC dependence, D gives me the tools to roll my own easily. (It's not as
if I don't already have to do it myself in C++ anyway -- and D is a
nicer language for it; I can generally get it done faster in D.)

Rather than take away "autonomy", D empowers me to choose whether I want
to do things manually or use the premade high-level niceties the
language affords me. (*And* D lets me mix high-level and low-level code
in the same language. I can even drop down to asm{} blocks if that's
what it takes. Now *that's* empowerment.) With C++, I HAVE to do
everything manually. It's actually less choice than D affords me.


T

-- 
People tell me I'm stubborn, but I refuse to accept it!