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