Why is D unpopular?

[Joshua]

On Saturday, 7 May 2022 at 19:30:08 UTC, Dukc wrote:
> On Friday, 6 May 2022 at 15:27:58 UTC, Ola Fosheim Grøstad 
> wrote:
>>> That doesn't mean if you have a webservice to write, that Go 
>>> is the "best tool for the job". D could be very well be the 
>>> "best tool for the job".
>>
>> D does not have cloud service support as I am aware of. Eco 
>> system matters.
>
> It is definitely true that comparing our ecosystem side-by-side 
> with Go or Rust, we lose. Even in general, let alone if 
> considering only the area where Go is presumably the strongest 
> at, web servers.
>
> But I argue that this does not always matter much. When you 
> need a library to do something, it does not matter whether you 
> have 5 or 50 good options. As Guillaume's DIID series shows, 
> D's ecosystem is easily big enough for most purposes. Of 
> course, most purposes != all purposes, but still. If you're 
> compare the languages in something where both D and Go/Rust 
> provide good libraries for, it's the language itself and it's 
> standard library that make most of the difference. Not the 
> ecosystem.

Yes.

I tried D a few times over the past twenty years or so, passing 
on it the first time over GC performance concerns (I was a bit of 
a purist) and the second time over uncertainty around D1 vs D2. I 
came back to it in the past week or two for use in a hobby 
project after trying many other options…

I’m so tired of jumping through hoops to combine build systems 
just so I can use one neat Go library or one neat Rust library or 
just build most (but not all) of mobile app in Flutter/Dart 
…however, the standard libraries for these languages don’t 
support UUIDs or graphemes, so I need to pull in even more 
dependencies and then one hobby coder owning a small test helper 
project ten layers deep in my dependency graph introduces a 
subtle incompatibility that ripples through my whole build system 
and I’m almost back to square one. It would be nice if choosing a 
language didn’t have to mean choosing the entire build system and 
ecosystem of hobby projects that comes with it. Worse, these 
build systems’ support for mixing languages is mostly 
superficial. Rust’s Cargo, for example, or Go’s Get, are neither 
optional nor easy to integrate into other build systems. Have you 
ever tried combining C++ and Rust in the same project?

So I keep looking back to C++ or even C to just build a 
cross-platform base that can be extended with plugins written in 
whatever other language, and then scripting languages start to 
look good. Lately I started looking at compiled functional 
languages that integrate easily with C because I expect I’ll need 
their expressiveness and type safety for some tricky data 
transformations. OCaml gets pretty close - if it came with 
pkg-config support to find the runtime library, I might even have 
stopped there! However, I looked even further and found D has it 
all: it’s compiled, it integrates easily with existing C code 
whether I’m using  GCC or Clang, it doesn’t force me to use a 
bespoke build system (I’m avoiding DUB so far, Meson is good for 
me), and wonder of wonders: it has standard library support for 
iterating through Unicode text one grapheme at a time! Well I’m 
sure I’ll encounter a rough edge or two. Maybe I’ll even move on 
again. However, with CTFE and lazy parameters to boot it’ll take 
more than one or two scrapes to shake my newfound hope in this 
language.