D needs to learn from competing languages and ecosystems.

[Claudio Constantin]

Hello!

I want to express my genuine interest in learning D as well as 
the friction I'm facing in doing so, and at the same time, relay 
my thoughts on what I believe would improve adoption.

First, a bit about myself so you can understand where I am coming 
from.

I started programming during the Covid era because there was 
nothing else for me to do.
I'm 25, so nowhere near as experienced as many of you here. 
Despite that, I want to write this to try and share my 
perspective on things I have seen evolve.

Lady Luck smiled and I got a job as an Android dev, so most of my 
not-so-long career has revolved around Java, and now we're 
migrating to Kotlin/Jetpack Compose.

Since then I have explored more programming topics and languages, 
because for me it's fun.
It's fun to learn and do things.

It was inevitable to not hear about Rust a couple years ago, but 
then I tried it and fell in love with it.

Admiration towards Rust is often attributed to the language 
design, which is fair. However, I don't think its popularity 
exploded because of how good the language was, but because of how 
complete the experience was.

Cargo, rustfmt, rust-analyzer, clippy, MIRI, rustdoc... 
everything provided in one package, under the Rust Project 
umbrella (rust-analyzer wasn't originally part of it, it is now).

This meant that with one VSCode extension and a shell command, 
you could get a DX experience that would later set the standard 
for expected language tooling.

Rust wasn't the only language providing a batteries included 
experience, Golang and Dart (the DSL for Flutter) also provided a 
frictionless pipeline.

One can argue that Dart never took off, but both Rust and Go did, 
and while the *languages* themselves were good, I doubt their 
adoption would have been as good weren't for their complete 
toolchains.

Newer projects like Zig or Odin, competing with Rust, C(++) and 
D, have taken stances that hinder their growth.

I'll only focus on one part that I believe is crucial, the 
language server.

Zig has ZLS, but the Zig foundation refuses to adopt ZLS as an 
official project.
Despite Zig being an interesting language, the language server is 
underwhelming in capabilities and understanding of codebases as a 
whole.

This type of friction actively hurts adoption and is an issue 
that must be addressed with urgency.

The Zig Software Foundation relies on Zig doing well monetarily, 
and to me, this feels like self-sabotage.

Crystal, another very cool project, is suffering from low 
adoption due to bad tooling. The Crystal compiler was written in 
a way that never considered the importance of such tools.
Writing an LSP for Crystal isn't easy; therefore, Crystal has a 
lot of friction.

I could go on and on about this, but the point should be clear by 
now.

If a language wants to increase adoption, the experience must be 
batteries-included.

I have mentioned D competitors. However, other projects are 
starting to realize the importance of an owned toolchain, notably 
Kotlin, originally developed by JetBrains, has been taking steps 
to provide an official LSP, an official formatter and now an 
official build system (Kotlin Toolchain).

Same with Swift, developed by Apple. Swift went from a language 
that required specific hardware to even use to a (semi-)complete 
experience one can download with `winget install Swift.Toolchain`.

These decisions aren't made in a vacuum, and at first seem like 
bad financial decisions, as one company sells IDEs, and the other 
sells hardware.

Truth is, no one wants to use a closed source language, and no 
one wants a bad, slow DX.

Python and JavaScript tooling went from slow and all over the 
place to focused and fast. Projects like uv, ruff, ty/pyrefly and 
Deno, Bun, oxc/biome, tsgo over the JS side were created out of 
necessity, and a realization that yeah, this is pretty bad.

D is in an interesting position, it isn't as bad as Zig or 
Crystal, but not as good as Rust or Go. I could compare it more 
to something like dotnet.

But dotnet is working towards a better experience, their official 
LSP is publicly available (but it is in prerelease), and 
`dotnetup` is another official project, similar to rustup, that 
acts as an entry point to the language.

What I think D needs:
- Toolchain manager, its own version of uv, rustup, dotnetup, bun.
- An official LSP, owned by the Dlang project, developed in 
tandem with the compiler that should be easily managed.
- A tree-sitter parser, or at least adopt a community one, it is 
expected to have one nowadays.
- Extensions for popular code editors and IDE.
- An official book you can read online, both Rust and Go provide 
their own.

The items on this list aren't easy to develop and maintain, and 
there's a real cost, human and economic, behind each of them.
Do I think D could become the most popular programming language 
in the world if these things were done? No, I'm not that naive, 
but I'm 120% sure that interest would skyrocket.

D stands as a saner alternative to C++, which is why it interests 
me (and many others) in the first place.

By simply being a tinkerer and trying things out, I have seen the 
patterns that both successful and unsuccessful projects follow, 
and that's the conclusion I came to.

It is vital to attract that silent majority who had (or will 
have) an interest in D, looked at it and said "meh, not worth it".
They might install a compiler, try and use serve-d only to be 
slow and crash, write a small project to then only uninstall 
everything and move on. No feedback, no suggestions, simply 
apathy.

I'm not familiar with the sentiment in this community around 
adoption, or if it is even viewed as an issue, but my experience 
is this.

People expect something better, when you don't provide it, they 
don't tell you and carry on.

I'm eager to see what you guys think of my observations and 
proposals. Even if it all is wishful thinking without much 
acknowledgment of the real cost, I wholeheartedly believe it is 
what'll guarantee a better future for the project.