Developers developers developers developers

Core D Development Statistics

• 11 bugs fixed
• 19 bugs and enhancement requests opened
• 43 pull requests merged into the language: 34 into DMD, 3 into Phobos, and 6 into druntime.
• 9 pull requests merged into the website.

In the community

Community announcements

• DConf '22 Submission & Early-Bird Registration Deadlines
• [Semi-OT] Sdlang Initiative
• D for BigData: the first BetterC library by Tamediadigital
• Classes in D with betterC

See more at the announce forum.

Adam's rant

A problem I see in several D features is that they incur more costs than benefits on library developers, and this radiates outward as then there's either fewer libraries, or at the very least, support for the features for those who do want it is found lacking.

A long time member of the community did a bunch of work trying to add @safe to a library. This required changes to Phobos, which now flow downstream to other libraries, and took a fair chunk of work in the library in question. I asked: how many bugs were fixed in the process? He said not many. Significant cost, little benefit.

Another community member described the work he was doing to maintain betterC compatibility in a library he worked on. Quite a few hoops jumping through, and the big benefit cited is not that it improves the quality of the library, but rather that it maintains compatibility for other users of those esoteric settings.

I've talked before about the hundreds of lines of dub.json I have to maintain for other users which provide no benefit whatsoever for me.

I've similarly had trouble with the attributes. Indeed, I wrote about this back in 2016. And while looking at the archive, the author of vibe.d agreed back in 2015 - as it sits, the library author only has user pressure to add this, no direct motivation from the language or direct gains.

There are some language features that aren't terribly useful for "end users", but library developers can use them to make really cool things. (Arguably, this is the bulk of the Ruby language...) Then, library developers make an ecosystem that can be better than the language itself (I'd argue this is Python's greatest strength).

Many of D's features are very useful for library authors. But many of them are end-user oriented.... and leave the libraries behind. This is great for the DIY types, but not so great for a mainstream explosion.

Of course, since going mainstream doesn't benefit me either.... meh. Still, maybe library authors ought to get more consideration in these designs.