article comparing Rust and Zig, many points relevant to D

[SealabJaster]

On Wednesday, 10 March 2021 at 00:14:18 UTC, tsbockman wrote:
> 3) Small ecosystem
> ...
> However, what many of the people who would even *consider* 
> switching to D really want is reference counting and borrowing

And instead people see a bunch of different, incompatible memory 
management libraries for things like allocators, non-GC 
containers, and smart pointers, all of which are in varying 
states of completeness and buginess, and most of which aren't 
"standard" to use which makes it off-putting to spend any time at 
all with them.

Not to mention that just in general, D libraries are mostly hit 
or miss in terms of quality and whether they even function 
properly at all, or are supported for more than a week after 
they're released.

So then you look for a C# or a Java or so on version of what you 
want, and you'll usually find a well-document, 
actively-developed/well-tested featureful alternative that has 
some expectation of doing what you want without too much pain.

For example, 3 or so years ago me and a mentor wanted to write 
something that needed a database, and I thought it'd be a good 
time to introduce him to D. So after looking over and trying 
several database connectors on dub to varying levels of success 
(one couldn't handle SQL Server's nvarchar type; one couldn't 
connect for unknown reasons; one required external binaries we 
had trouble finding pre-compiled versions of and didn't want to 
spend time compiling it ourself, etc.).

So in the end, we decided to go with Entity Framework, where 
everything basically just worked and it could even 
reverse-engineer our database structure into a EF model. Not to 
say EF doesn't have its warts, but we were up and going within a 
fraction of the time spent just finding something in D that could 
actually function at all.

Meanwhile I had a sneaking suspicion that even if we got one of 
these libraries to work, there'd be some show-stopper bug that 
we'd run into even in our very simple use case.

Not to mention the rich resources and documentation on the 
internet for EF, while for a dub library the best you usually get 
is the README, and if you're lucky, some example files, or 
depressingly, vice-versa.

And I feel this is the point I often reach where I think: Is D 
really worth it for this project? Is D's productivity (as a 
language) going to be able to offset the un-productivity of its 
ecosystem that I shouldn't just go with C# + some mature library 
+ all the other bells and whistles I need (docs, examples, 
tutorials, etc.)?

I fear this is not uncommon, but I don't think there's any way to 
really measure this as a metric.

However, ecosystem aside we still used D for some mild data 
processing and generation, which D is really enjoyable to make 
use of.

That being said though, that was also a few years back, so I 
imagine it's somewhat better now, and there's a project I've been 
wanting to try to make so I might see for myself soon how things 
have improved.

> Buggy/incomplete/absent tooling

Slowly but surely. I'm quite happy with code-d now that it 
doesn't crash every time I make a new line, and that autocomplete 
doesn't suddenly stop working.

But the squiggles, oh dear me the squiggles.

Debugging is still annoying though, as you said.

I know I'm always quite negative about D in general, but that's 
due to a desire of wanting it to grow and improve, rather than 
malice.