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

[WraithGlade]

On Tuesday, 1 July 2025 at 05:47:47 UTC, monkyyy wrote:
> ...
>
> 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.

It is great that the Open D fork exists and is more open to 
change and refinement and I am interested in the future of the 
project and I think it increases the D language's chances of 
long-term survival.

I am unfortunately however still very much a D newbie though and 
thus I am very reluctant to depart from the mainline D ecosystem 
considering that even less library support and information will 
be available for Open D in all likelihood. I want to make real 
projects for redistribution to end-users.

As such, mainline D (DMD, GDC, and LDC) seems like a much wiser 
choice for an inexperienced user like me, even though I'll have 
to work around language limitations sometimes. I may try Open D 
later on though, depending on how things pan out with any 
projects I try and/or with mainline D's upcoming choices.


On Tuesday, 1 July 2025 at 06:31:58 UTC, Serg Gini wrote:
> ...
>
> D is not
> It is just small club of chill tinkerers.
>
> ...

Languages that don't sustain a large enough user base become at 
large risk of evaporating and becoming unusable in the future.

Tinkering is only an even remotely pleasant process when there is 
still a large enough library and community ecosystem to sustain 
sufficient tooling for such.

By analogy, all of computer technology itself is only even 
possible because of massive networks of interlocking human 
cooperation and engineering and massive compatibility efforts. No 
individual hobbyist could sustain the infrastructure to make 
computers even possible to obtain without that network of 
support. Much the same can be said of software.

Likewise, things like programming languages just as much must 
sustain sufficient scale or they too will become unusable over 
time even for hobbyists and tinkerers.

D's library ecosystem and community is currently *sufficient* but 
also flawed and somewhat *endangered* and is showing some cracks 
from insufficient scale. Other competing newly arisen systems 
programming languages (e.g. Zig and V) have grown *very quickly* 
despite being less capable than D.

There are surely reasons for that, such as perhaps especially the 
library ecosystem stability problems I've read about on the 
internet and shortcomings in clear communication and also of 
course GC being not very desirable for real-time systems.

Those problems could be improved by taking a much more serious 
stance regarding the critical importance of having very strong 
libraries if a programming language seeks widespread real use, 
among other things of course.

(Also, tangentially: deterministic reference counting like C++ 
smart objects, reliably controlled by destructors based on 
scopes, would be better than any unpredictable non-deterministic 
GC and still obviate the need for complicated memory logic such 
as Rust suffers from and would still be on par with what modern 
C++ performance is like, especially since structures on the stack 
or in pools wouldn't need allocated dynamically as such at all. I 
am not sure why so many languages don't realize that 
deterministic reference counting is a great middle ground between 
the two extremes of GC and non-GC approaches.)


On Tuesday, 1 July 2025 at 09:59:46 UTC, Kapendev wrote:
> ...
>
> I think having an official "vendor" library collection tied to 
> the language is a bad idea. Sure, it feels nice to just `import 
> raylib`, but it couples library updates to language versions, 
> making it harder to get new features or fixes without upgrading 
> the entire language. It also limits what the libraries can do. 
> "Official" libraries have to stick to a common standard, which 
> prevents them from offering extra features or even 
> documentation. It's easy to not think about these things, but 
> they are important. Independent projects can do that much 
> better. A curated list like awesome-d is a better solution and 
> has worked for so many languages until now. It can highlight 
> great libraries without tying them to the language.
>
> Anyway, 
> [awesome-d](https://github.com/dlang-community/awesome-d) is 
> awesome!

Awesome D is a good list and is where I found what D libraries 
where available to try, but it did *little to nothing* to change 
the fact that many of the linked libraries have poor installation 
instructions that could be automated (and automation is largely 
the whole point of programming... which makes that ironic) and 
questionable viability for real software production.

Even besides many of such libraries seemingly not working at all 
even for basic examples without having in-depth knowledge of how 
to set things up that new users to D could never be expected know 
in advance (akin to a "chicken and egg" problem), the existence 
of such lists does not do much to assure stability of the 
ecosystem in light of the fact that the "standard" for what is 
needed for a programming language has expanded greatly beyond 
what was considered a sufficient range of built-in abilities for 
languages in the 1970s and such. The world has changed a lot 
since then, but many people's mindsets haven't kept pace.

**Library ecosystem health remains one of the most dominant 
factors in language viability, if not literally the most dominant 
factor in reality**. Many of the most popular language survive 
basically entirely based on that criteria even despite being far 
worse in core language design and thus not acknowledging that 
reality and planning strategically accordingly is a recipe for 
greatly reduced uptake and survivability.

Also, importantly, **there is nothing that says that "blessed" or 
"vendor" libraries have to stay in lockstep with the language's 
standard library**. That is a complete *non-sequitur* and is 
unrelated to anything I said. Partial official support (i.e. just 
routinely making sure at least one multimedia library is as easy 
to use and polished as possible) is not the same thing as being 
tied to the hip to the language core and standard library.

**Nothing about my suggestion in any way ties any library to the 
core language or standard library.** Nothing about it limits what 
it can do nor impedes documentation in any way either and indeed 
rather it in reality *encourages* better documentation by forcing 
D to ensure a proper API and integration of whichever 
"blessed"/"vendor" library(s) it chooses. Streamlining a library 
experience also inherently means it needs fantastic documentation 
written with high user empathy and care. Poorly documented or 
undocumented features might as well not exist from the standpoint 
of average users.

The criticisms you bring up are all just conflations of unrelated 
things, basically.

It reminds my of how over a decade ago I remember someone on a 
C++ forum argued that nestable comments were *impossible* to ever 
implement because they allegedly weren't logically consistent, 
but in reality that was a conflation and of course has no basis 
in 1st principles based thinking but rather was tied to 
preexisting ways of doing things that were left subconsciously 
unquestioned.

In that regard: An in-between status between official language 
facilities and 3rd party libraries is *not* merely a synonym for 
official language facilities and thus does not have the same 
characteristics. Indeed that is the entire point of why it is an 
*in-between* and *semi-standard* status and not part of the 
standard library itself and is why I made sure to describe it 
that way for clarity.

Multiple independent libraries can be officially maintained 
separately. As long as such libraries never change the core 
language itself then there is never a reason they would ever have 
to stay in lockstep.

--------

More broadly speaking though (addressing everyone now), I think 
historically (from what I can guess from browsing D's forums off 
and on over time) the speed and frequency of dismissiveness and 
negativity and lack of imagination on these forums seems likely 
to have probably played a role in D's historical stagnation that 
have held it back despite D having years of ample opportunity to 
carve more of a space for itself. It is still a great language 
anyway, but the point still stands.

I also wanted to mention that I think the following are 
strategically wise for D:

- competing better with Rust (the core D team's exploration of 
safety in this regard actually seems like a smart move in light 
of the new emphasis on safety in the industry)
- improving the library ecosystem, especially those packages 
essential for real world software such as immediate mode 
multimedia libraries (such as SDL or Raylib or Sokol) and 
retained mode GUI libraries (such as Qt and wxWidgets etc or 
similar) seems likely to help too
- better communication and "advertising" of the language to get 
the word out

Long-term though I think the C family of languages main real 
advantage is native-level performance and it will only be a 
matter of time before a non-C family language with better syntax 
(such as mixfix syntax and concatenative semantics in my personal 
theory) eventually displaces the C family from their dominance of 
the most popular languages.