Should I invest time in D?

[Don Allen]

On Wednesday, 17 January 2024 at 17:34:14 UTC, Renato wrote:
> On Wednesday, 17 January 2024 at 07:19:28 UTC, Lars Johansson 
> wrote:
>> After years of procrastination, I at the end of last year 
>> finalized Rey Valesa's great dlang/vibe tutorial   
>> https://forum.dlang.org/thread/gnluupbilugncznkffuo@forum.dlang.org.
>> I had planned to proceed with a deep dive into D.
>>
>> With the post 'Cloning D', it looks like Pandora's box has 
>> opened.
>> I do not want to be a part of such community and the future of 
>> D does not look good. The alternatives do not look good 
>> either. Immature, boring, too restrictive etc. Is assembler 
>> the choice if you want to add a low level language to your 
>> Intel toolbox?
>> I'm seventy one, so I do not have all the time in the world.  
>> I have procrastinated too long already. My humble question is 
>> 'Why should I use D?'. I am greatful for any polite answer:)
>
> I've just started using D myself... so I can perhaps give a 
> perspective from someone coming from a similar position.
>
> D has a lot of depth. Initially, it looked like Java with 
> pointers to me, but as I learned more about it, I saw a lot of 
> stuff I had totally not anticipated, e.g. the metaprogramming 
> which is just about as powerful as in Zig, though everyone acts 
> like Zig invented it. But to fully understand the features, 
> just going through the D Tour is not enough (though it's a 
> really good start!)... you really need to write some stuff in 
> it and see how it feels.
>
> About the polemic going on in the community: I am completely 
> ignoring that. Every language that allows passionate people to 
> participate in the language development ends up with the exact 
> same thing. Have you seen the sh*thow going on in the Rust 
> community (people being invited to conferences then being 
> cancelled at the last minute, their Foundation trying to 
> copyright the use of the name Rust, some of the core developers 
> resigning publicly over some power play... the list goes on)?
>
> Have you read blog posts about disgruntled developers spending 
> decades on Scala and then finally leaving with a big rant (it 
> was a running joke for a while that you must rage quit with a 
> huge blog post if you're a real Scala dev)?? Apparently that 
> has happened almost exactly the same in D (I've been reading 
> too many thread here lately!). This is just how developers are 
> (perhaps more than the general population) - they want to be 
> heard, and if they're not they feel like they're 
> underappreciated, that their genius is not being recognized and 
> that other people are fools for not seeing that...
>
> Anyway, stay away from all that - it just doesn't matter when 
> you're working on something cool using a language you enjoy.
>
> The things I like in D:
>
> * at least 3 different compilers. This is more important than 
> people may realize!
> * good, useful features.
> * mature enough (though less than I expected from its 20-year 
> history).
> * simple to use (most of the time).
> * compiles fast, runs fast (though [it can be slow 
> too](https://forum.dlang.org/thread/bpcchllrascnjsrszheb@forum.dlang.org) if care is not taken, or super fast if you know what you're doing - see the linked thread to the end).
> * @nogc, @safe, @nothrow etc. the more the compiler can verify, 
> the better!
>
> Things I didn't really like much:
>
> * package manger is good but almost completely undocumented (I 
> already made PRs documenting the stuff I learned - hope they'll 
> merge [the latest 
> one](https://github.com/dlang/dub-docs/pull/84)).
> * not very "search" friendly due to moderate popularity so not 
> many questions with answers can be found.
> * veteran users seem to love to complain about the language 
> (regardless of the politics going on). That's a bad sign... 
> Rust people rarely do that (except for the async debacle).
> * testing is built-in (awesome!) but test reporting is terrible 
> (though packages do exist to make it better - but again, 
> difficult to find solutions).
> * some constructs are very IDE-unfriendly (a downside of 
> CTFE/metaprogramming stuff I think, Zig has similar 
> "untyped"-looking - though actually typesafe - stuff).
> * tooling seems subpar. VSCode is the only IDE that actually 
> works well and I would've preferred to use emacs or Kate (which 
> do work, but you have to suffer to  make it usable). Tried 
> profiling and it was very underwhelming. Couldn't get debugging 
> working yet.. but didn't try very hard.
>
> I am not sure yet I'll stick with D, but after 3 or so weeks I 
> am still here :D - tried Zig and Nim as well, and looked into 
> Odin, but those are so immature it's definitely going to be 
> years before they're generally usable... D is usable today. 
> It's not perfect for sure, but it seems to be getting better, I 
> just hope it doesn't get more "difficult" features and instead 
> trims down a bit on the complex stuff (like all the subtle 
> differences between pointers and `ref`, `in`, `out`, `inout`, 
> `scope`, `const` and so on - that kind of stuff should be much 
> simpler IMHO).
>
> In conclusion: if you want a good low-level, mature language 
> that has good tooling, I would go for Rust instead... but I 
> don't like the slow compilation times and millions of 
> dependencies for anything beyond hello world, so D is kind of a 
> nice compromise for me :D no offence to anyone. It's not as 
> fast, not as powerful... not as popular... not as safe even... 
> but it's simpler to use and just feels more fun without being 
> overly yolo like Nim, or completely raw like Zig and Odin! A 
> good middleground I would say.

Excellent analysis. I've done the same language tour myself. I've 
written a fair amount of Rust, and concluded that it is the most 
difficult programming language to master that I've ever 
encountered, and I've been doing this a *very* long time. And I 
have a lot of Haskell experience. But once you find the Rust 
gotchas that get you into lifetime hell or a big fight with the 
borrow checker, it's excellent. Like Haskell, once you have the 
blessing of the compiler, your program will run. Not necessarily 
correctly, of course, but you won't need gdb to fix it. As you 
said, the tooling is good. I will comment that I really dislike 
much of the documentation, starting with the "affectionately 
named" (ugh) Book. The Jim Blandy book is orders of magnitude 
better. The library documentation is also not great, but it's 
usable.

Despite all the recent tearing of hair and rending of clothing, I 
think D is very, very good. What it offers that Rust does not is 
a strong connection to C and C++. So if you are experienced in 
those languages, you will feel comfortable in D pretty quickly. 
You also find that a lot of the many rough edges in both 
languages are gone. D also has valuable capabilities that C and 
C++ do not. The garbage collector is a big plus, in my opinion. 
Those who dismiss D because it has a GC don't know what they are 
talking about. D offers multiple memory-management techniques; 
using GC-managed storage is only one and can easily be avoided. 
Or minimized. But having it there can really simplify your 
programming life.

Another important aspect of D is the ability to use C libraries 
directly, without need for bindings. Much of the work I did in 
Rust involved gtk and the Rust gtk "crate" is hard to use and 
poorly documented. In D, you use gtk as you would in C. I did my 
D-gtk work before ImportC was available, so I wrote my own 
function prototypes for the gtk functions I use. While ImportC is 
very nice, one issue is that the C library headers tend to be 
sloppy about mutability. So if you care about not following their 
careless lead in the declaration of your own variables, use of 
ImportC can lead to a lot of casts, particularly of strings that 
are immutable but the C headers don't say so.

Your listing of the downsides of D is fair, I think. I've avoided 
using dub for precisely the reason you note -- the lack of 
documentation. The language reference is generally good, very 
thorough, but it is inaccurate in places. And at least in the 
past, I've felt that PRs about those problems don't get prompt 
attention (I haven't checked recently), probably one of the 
symptoms of the small D developer community. I do think Ali 
Çehreli's book is very good and getting better all the time.