We've gone a step further with ImportC, and now C code can be imported directly into the D compiler, which makes it easy to interface D code to your existing C base.

I've never had a chance to look at it much, but I think the magic is in the metaprogramming capabilities. It's more principled than C++ templates, more ergonomic than Scala macros, and more practical than Template Haskell. Somehow. (At least this was my impression from discussing it)

But, I think one of the things that people seemed very happy about feature-wise that started to turn me off the language was UFCS. I don't deny that it makes the written code look more elegant but I think to me it existed as a net negative for other people who are unfamiliar with the code they are reading. There was an example someone gave years ago on reddit that was supposed to convey how clean the code to solve the problem was but it included an UFCS expression of the form 'a.b!c.d' which was sans-UFCS 'd(b!c(a))'. Trying to determine which reordering the compile would going to eventually choose seemed like more work than should be necessary for simple expression like that.

Having said all that it still might be a good choice for certain development environments and I should see whether there's a second edition of TDPL.

  "...was originally released under a custom license, qualifying as source available but not conforming to the open source definition. In 2014..."

Parallel to this, other programming languages became more popular and evolved, particularly C++. This certainly affected D's "novelty value".

I wonder how much these facts negatively influenced D adoption.

This is a weird thing to call out java for: you cannot inherit from multiple classes there. You can only get a diamond if you inherit two interfaces with default implementations of a method on a shared parent interface. Over a decade of writing java, I hit this zero times. In any case, Java treats it as a compile error and forces explicit resolution instead of silently doing something confusing.

On a more serious note it's cool to see the languages creator quite frequently on HN - it is the reason I took a look at it a while ago :)

i had two abortive attempts to use the language for specific projects - one was to wrap a C++ library and use it from D, but it turned out the swig bindings didn't work.

the second was to find an active gtkd-based app and contribute to it, to get a feel for desktop gui development (which seems on the surface like a very compelling use case for the language), but after asking on reddit no one could suggest anything other than tilix, on which development has stalled :( i would still love to do this, if anyone has something to suggest.

if anyone is involved in a fun desktop-based D project (CLI, TUI or GUI are all fine) please recommend it!

    // Increment all elements by one (array-wise expression)
    half[] += 1;

I wonder how many people are missing out on Go for a feature they wouldnt miss 80-90% of the time?

It helps keep structs small and simple, rather than becoming kitchen sinks.

D had some missteps along the way that lost some initial traction. I also wouldn't be surprised if timing was a factor with more C++ warts being added while the programming community has learned more lessons along the way that could be applied to the next languages (Go, Rust).

As I followed D, the problems I remember there being were:

- Compiler availability (DMD vs GCC)

- Split stdlib

- It was aiming for C/C++ post-Java but covered more Java use case (GC) than the remaining C/C++ ones (no-GC). It took a while before BetterC. No idea how well that ecosystem has matured.

- It felt like they were shoehorning every feature into the language rather than having a cohesive design strategy

These have slowly been resolving but Rust is now here, targets most of BetterC's use cases by default, and the borrow checker has let me squeeze out performance out of my code that would have been irresponsible without the compiler making it maintainable.

But the language just wasn't for me. Right off the bat, the default import style which thrusts everything exported into the default namespace like C seems odd at this point. Apparently one can use what are called static imports, but as a code reader I can't enforce it.

It feels a lot like a language for C(++) folks, who IMO tend to be more conservative and entrenched.

Given the initial paragraph, maybe I'm just not smart enough to grok it :).

I know Ruby, so here is what I'm used to:

  half.map { |i| i + 1 }

  Enum.map(half, fn i -> i + 1 end)

  half.map(i => i + 1) // It looks just like the Ruby one

Compare all those to the aforementioned D version :

  half[] += 1;

EDITED to fix little mistakes.

You can also mix and match scalar and slices, so for audio code it's quite cool:

    a[0..frames] += b[0..frames] * volume;

In this case the syntax lowers to a template which handles the iteration for you. It is not special, it gets treated the same by the compiler backend, but it will almost definitely be inlined & vectorized if the compiler is allowed to.

GCC and LLVM are actually clever enough to call memset for you if they deem it profitable.

Looking at the notes, it may have separate syntax to make compiler vectorization and parallelization easier. Plus it's pretty terse.