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.
