Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Benny]

On Thursday, 25 January 2018 at 19:53:39 UTC, Basile B. wrote:

> If you write OOP with few templates like often done in C#, 
> Delphi, or more declarative style like Go or C, then DCD works 
> fine. Your frustration probably comes from the fact that 
> popular techniques in D are not supported by DCD: Template 
> Metaprogramming and CTFE.

Maybe there has been a misunderstanding but i am not talking 
about CTFE or Metaprogramming. Basic OOP does not even work. And 
that is after testing D plugins going back a year or more with 
several DMD/Dub releases at the times.

On Thursday, 25 January 2018 at 17:32:24 UTC, Andre Pany wrote:
> While the several tools out of the box do not work well 
> together, the involved developers
> did a great job (without any payment in contrast to Go/C#, 
> Delphi...). I also struggled with the problem how to configure 
> DCD in the DLang plugin for IntelliJ today.
> This might be the reason for the items marked as unknown.
> I created an issue here 
> https://github.com/intellij-dlanguage/intellij-dlanguage/issues/356
>

Most of the plugins mentioned here are also made by community or 
individual members. The issue ends up being that its not so much 
the Editor plugins that create the problems but whatever language 
server that is behind it. Please look up several of the plugins 
there originals and you will see a lot are made by individuals? 
For instance OmniPascal...

In my eyes its not the plugin authors there problem because they 
need the official tooling support from D. Compile a set of tools 
and notice how many deprecated calls show up. Or issues when a 
new D compiler version gets released. Or a new Dub version that 
breaks the tooling left or right. This is what i mean by "not 
properly cross platform tested". There seems to be a total lack 
for any tool "chain testing" beyond individual stand alone tests. 
How else does one explain the constant issues i have personally 
faced ( and reported ).


I have been in the position to use D in several projects but in 
my experience its not worth taking the risk ( when issues like 
this keep happening ). This also affect not just the tooling but 
also the whole public dub packages.

When a new language like Rust is more tooling friendly and its 
extended platform integrates great with the editor plugins... Its 
not like Mozilla has hundreds of Engineers on Rust. Its extreme 
highly community driven.

It seems to be that they understand the value of better tooling 
and friendly platform support. Whereas its my impression that a 
lot of resources get focused on making D its compiler / language 
better but the rest seems to be ignored.

I am sorry if this sounds cruel but for now D is on the back 
burner and my next project will probably be in Rust. Its a real 
shame but when even things like editor plugins barely work it 
makes me doubt the rest of the platform. And i do not even like 
Rust as a language but one can not deny it is a better supported 
platform.

One can only express their hope that there will be a 
revitalization in the D management and the priorities. From my 
point of view it feels like D is falling behind when compared to 
other languages like Rust/C++/Go/... D really needs a project 
leader that knows the language and starts focusing the resources 
beyond just the compiler.

Anyway, good luck in the future.