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 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.
Permalink
Reply
