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

[monkyyy]

On Tuesday, 1 July 2025 at 02:08:57 UTC, WraithGlade wrote:
> 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.

come to opend, upstream is barely interested in making the std 
have new uses instead they want to add "safety" "features" you 
will be told dub is perfect and everything you could every want 
in an npm clone and the community barely realizes how to run the 
compiler at all.

You wont win this fight, it will be smashing your head into a 
brick wall.