D tooling is disappointing

[Laurent Tréguier]

On Wednesday, 17 August 2022 at 10:45:16 UTC, tastyminerals wrote:
> _This is a longer than average post where I mostly express 
> personal concerns about things that you probably heard 100 of 
> times..._
>
> Many of us use vim for quick scripting and if so, you know 
> about handy [vim-dutyl](https://github.com/idanarye/vim-dutyl) 
> plugin. If you're a MacVim user, you might already know about 
> sad [d-completion-daemon status in 
> MacPorts](https://i.imgur.com/qUtRpG3.png). There is no 
> maintainer for the only usable D autocompletion plugin for Vim. 
> Truth to be told, the actual vim-dutyl looks abandoned too.
>
> I also use VSCode on Mac, it has a great **code-d** extension 
> installed. But unfortunately, it doesn't really work popping up 
> with notorious
>
>> Could not initialize dub for 
>> /Users/tasty/Dev/document-sender-app. Falling back to limited 
>> functionality!
> Cannot use dub with invalid configuration
>
> Tried fixing it but without success. I had some issues with the 
> code-d plugin on Windows some years ago too. Then it was 
> updated, and now it works fine. The problem is that I use Mac 
> for daily work and I love scripting, and I believe D is an 
> excellent scripting language.
>
> Now, here I would like to step back and just express that I am, 
> a casual D user, is pretty sad by the state of the D tooling. 
> It's nowhere close to much younger languages that have a decent 
> IDE support. Now, I am confident that whoever works hard today 
> on D is aware of this. And yet I think it is important to 
> stress again, that great IDE support, autocompletion, and doc 
> hints for such a rich standard library as Phobos are very 
> important. It is the lobby, the entrance gates to any newcomer 
> interested in learning the language. And we are not even 
> talking about productivity gains that proper language support 
> can deliver.
>
> If someone asks me about current D language tooling, I would 
> have to confess that it is lackluster. But, hey, some of us use 
> nano to program in D, right?
>
> Having read numerous posts about how D is not popular, the 
> community is small, there is not enough people and such. I hope 
> the people who invested far more than me into this great 
> language, focus on something that can be achieved with the 
> resources that you have right now. Because, you know, it feels 
> sad to read dozens of comments about how better to implement 
> some language feature in the upcoming DIP while looking at the 
> state of its support in IDE. And let's not forget that D is >20 
> years old. I wish someone at DConf talked about this mundane, 
> casual but really important problems that D has.
>
> This is nowhere a critic to the tons of work that WebFreak001 
> does, but rather feedback or probably an accumulated 
> disappointment with things that I believe can be easily tackled 
> with a community effort.

I don't hang around this forum much anymore, but as luck would 
have it I took a peek today and saw this recent post.

I used to work on D tooling myself, precisely because I also 
thought it was not good enough, and unlike a good chunk of the D 
folks, I love having some fancy IDE do all kinds of things like 
context-sensitive auto-completion, project-wide symbol renaming, 
dynamic linting without having to compile anything...

In my opinion, there are 2 major issues, both of them have been 
touched upon in this thread I think.

One of them is the small community that doesn't mind the lack of 
advanced tooling, paired with a strong DIY mentality. Many people 
new to D probably faced this exact issue, they come and realize 
the tooling is subpar, then get told to work on it themselves if 
they want something better, and quickly move on to greener 
pastures.

The second is the language itself. D code is often littered with 
a lot of template-heavy code, which makes type inference 
difficult, and can thus cripple the capabilities of the editor as 
tons of variables have opaque types for which auto-completion and 
linting become impossible. The syntax itself had a few tricks up 
its sleeve as well IIRC, I remember relying sometimes on code 
conventions for my syntax highlighting.

I have no clue where serve-d is at currently, but back when I was 
working on D tooling, both it and my language server were using 
the same trio of DCD, D-Scanner and DFMT, which themselves had 
their own quirks as well, adding an extra layer of brittleness.

In order to go beyond their limits, at some point I tried 
experimenting with using DMD as a library, in the hope to get 
template resolution and such, however this wasn't easily done 
either, because DMD was never meant to be used inside of a 
language server. Firstly, it has a global state that doesn't play 
well with the nature of language servers (long-running processes, 
just like web servers). And secondly, it sometimes uses stdout, 
which is typically what language servers use communicate to 
editors, meaning DMD would have to be patched in order to be 
technically usable (without even thinking about how to then use 
its capabilities).

The last idea I had was to use tree-sitter [1] to make a server 
"from scratch", without using a tool for something it was not 
meant to be used for, and only using a parsing library. I never 
finished my tree-sitter syntax file for D though, some specific 
string syntaxes had to be done in code directly outside of the 
syntax file, and as I was working on another project, I gave up.

The problem of D's tooling is old, and will probably never be 
completely solved. As you said at the start of your post, this is 
hardly the first time this comes up. I predict it's also not 
going to be the last.

If I ever came back to D, I would probably try to use tree-sitter 
again to make some new D tooling: it is made specifically for 
parsing code at every keystroke in an editor while being embedded 
without any dependency. That's my conclusion for anyone crazy 
enough to dive into this...

[1] https://tree-sitter.github.io/tree-sitter/