What are the prominent upsides of the D programming language?

[data pulverizer]

On Monday, 21 September 2020 at 11:04:43 UTC, Imperatorn wrote:
> Top reasons to use D instead of for example Rust, Julia, Go etc 
> :)

 From my experience:

# Rust

## Pros

Great introductory material and generally well documented, and 
shallow learning curve but you need to be prepared to adapt to a 
different way of doing things. If you do as the documentation 
says, you will have remarkably few problems.

## Cons (w.r.t D)

Far more difficult and poorly documented integration with C than 
in D. You can write C code and call it from Rust but just try 
calling BLAS from Rust - that's a headache, but it's 
comparatively child's play in D.

Rust doesn't ship with a threading library or parallel for loop 
in its standard library. In this day and age that's a non-starter 
for me.

I wonder whether completely shifting your programming style to 
Rust is worth it when I tend to segfault in D only once or twice 
every 6 months (if I'm intensively coding D), they are easy fixes 
(within 5-10 minutes) and usually happen when I've called a C 
library in an incorrect way.


# Julia

## Pros

Great introductory material and generally well documented. Since 
it is a dynamic language beginners can lean on the dynamic 
notation until they understand the typed side. Also great 
performance and out-of-the-box scientific data structures and 
algorithms. Its multiple dispatch OOP is very convenient and 
easy, great collection of programming paradigms and a well 
designed language. Can call C libraries easily. Easy to write 
code abuse when you need to because it has embedded compiler and 
is dynamic but also typed. Very good interpreter.

## Cons (w.r.t D)

Can't distribute proprietary libraries/modules, no dlls so people 
will see the implementations.

Pointers and references are in their infancy, constants are not 
really constant, even though it is typed, it has poor support for 
other things static languages take for granted, e.g. good enums, 
static, and so forth.

Long compile times for various libraries which can take between 
10 seconds to over a minute to compile even simple libraries, and 
they need to be compiled each time they are loaded. If you are 
working with libraries, you can suddenly come to a standstill 
when you have to wait for the function/module to compile.

Even though it's technically a "dynamic" language, I think it's 
somewhere in between. I'm not sure you can call a language 
"dynamic" if it has a compiler backend embedded built into it 
that causes very long all-stops. I feel as if there is a bit of 
"slight of hand" in that definition, but whatever.

IMO, defaulting to private in a module is the wrong call, but you 
also you have write export lists a bit like a header file [Gag!].

You have to be careful about how you write code since the 
compiler can mark things dynamic rather than creating efficient 
code for it. It requires experience and constant vigilance using 
the provided tools. Writing an object one way rather than another 
can have a massivley deliterious effect on performance, and with 
a drive to "simplify" coding by leaving out type information and 
so forth, it's something that can easily happen.

Julia is a useful langage but it not a panacea, you have to take 
extra care to understand why you are using it, because it doesn't 
easily fall into the usual categories of programming languages.


# Golang
Don't know much about Golang, but I don't tend to take modern 
static languages with no templates/parametric polymorphism 
seriously.


# Nim

## Pros

You didn't ask for this but Nim is worth mentioning. Fantastic 
base language, very easy integration with C, great performance. 
C/C++/JavaScript backends are an inspired move.

## Cons (w.r.t D)

Very poor documentation, the official book doesn't even begin to 
touch the usefulness of Ali's "Programming in D".

Poor standard library, for example the threading library doesn't 
even begin to compare with D's or indeed parallel for loops in D. 
Currenly in Nim's standard library, the parallel for loop will 
seriously malfunction in a variety of ways for example, if you 
are trying to read/write to then same array (in different 
locations) - apparently there's no current fix for that apart 
from using another library (which kind of defeats the purpose of 
a standard library). I found the syntax a little tricky at first, 
which wasn't helped by the lack of documentation. Module items 
default to private but not as bad as Julia because you can export 
with a simple asterix next to the implementation.