Having "blessed" 3rd party libraries may make D more popular and stable for building real software.

WraithGlade wraithglade at protonmail.com
Tue Jul 1 02:08:57 UTC 2025


There's a trend I've noticed among some of the newer programming 
languages that have managed to grow their communities despite 
being so small: some of them have partial official support for 
one or more of the most useful 3rd party libraries.

The language maintainers themselves make sure that the interfaces 
and process for getting those libraries working is streamlined 
and polished and a pleasant and reliable experience and treat it 
like a kind of in-between or semi-official library status. It 
brings more nuance and gradation into the notion of what language 
support means for a library.

Basically, there's a longstanding fiction in languages that 
somehow only file access and communication with the OS text 
terminal/shell and the various data structures and algorithms and 
concurrency primitives (etc) somehow constitute a sufficient 
foundational library for making real modern software, but really 
most modern software that average users actually care about 
basically can't be made without access to the multimedia 
(graphics, sound, input, etc) components of the computer.

Relying in an entirely hands-off way on 3rd parties (who often 
become active or inactive at random and thus can't be relied upon 
much) for all such libraries makes the ecosystem of a language 
vulnerable and hence less likely to be used in real software.

Having one or more officially backed ("blessed" or "vendor") 
libraries helps ensure that a programming language remains usable 
for real software more consistently and decreases the chances 
people will be deterred due to having difficulty getting the 
basics working.

The best library candidates for such if you ask me are libraries 
like SDL or Raylib or Sokol or Love2D (though the last is Lua 
based, not C based). Having even one such library be as polished 
and as seamless of an experience as possible increases the 
viability of the ecosystem.

Granted, `dub` makes some of these libraries easy to set up, but 
it is still easy to mess up during an install or to miss a 
critical bit of info (etc) and that likely deters more people 
from using D.

Some such libraries are easier and/or much more clearly 
communicated than others, such as Raylib and Sokol for D being 
relatively easy to set up (though Sokol has some dependencies 
that are easy to overlook and create needless difficulties in the 
setup process), whereas others such as the BindBC bindings seem 
bewildering and hard to get even the most basic examples working 
for and have instructions that can only be readily understood if 
you already know more things about the library than a new user of 
it and/or of D would know.

Indeed, broadly speaking, **library ecosystem health is often 
even more important for user adoption than core language feature 
development is**. That's a reality that matters if a language 
seeks to survive and thrive. If libraries don't seem to work with 
*minimal* effort then new users may see no apparent path forward 
and may even drop the whole language in frustration.

In fact, it seems like there is some evidence that precisely that 
problem has historically played a large role in D not being as 
popular as it seems to deserve to be.

I have seen multiple old forum comments where people say they 
just gave up because they couldn't manage to use D for real 
software even though they really *wanted* to.

That suggests that friction in the uptake process for D's library 
ecosystem is playing a big role or at least historically has.

At least some libraries are easy to set up (like D's newest 
Raylib bindings), but expecting users to randomly stumble on the 
right libraries for ease of use is asking for losing a large 
percentage of them to them getting frustrated before they ever 
gain enough momentum to feel confident that they can rely on the 
language for real work and not just for playing around with the 
core language itself.

Picking an expressive and broadly capable but not overly 
complicated multimedia library (such as SDL or Raylib or Sokol) 
and making it **as easy to use as the standard library itself and 
perhaps even shipping it with every standard copy of D** and 
perhaps even rewriting the library entirely in D or at least 
wrapping it to be more seamless than a mere binding could go a 
long way to improving the D ecosystem over time.

Anyway, that's my thoughts on it and thank you for reading.

D is great regardless and `dub` is especially helpful in 
navigating these issues.

If D seeks more users though then it would benefit from an even 
more communicative and seamless ecosystem.


More information about the dip.ideas mailing list