After months doing a different project, i need a programming language for a new client with specific needs. D comes to mind. As usual that involves downloading the compiler (dmd and ldc).

So, lets install Visual Studio Code:

* Code-D Plugin:
  - Syntax highlight *check*
  - After saving: DMD error suggestions in the code. *check*
  - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space).
  - ... and nothing else...


So lets try the next plugin:


* Serve-D Plugin:
  - Syntax highlight *check*
  - After saving: DMD error suggestions in the code. *check*
  - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space).
  - ... and nothing else...


Frustration level increasing. Lets try the next one:


* D-Language Plugin:
  - Syntax highlight *check*
  - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space).
  - ... and nothing else...


Ok ... so Visual Studio Code its Dscanner, DCD, Workspace-d do not properly work or some other issue.


Then lets try IntelliJ Community Edition. After a long time getting all the dependancies and compiling them... Dscanner - DCD ( client and server ) - Dfix ...


* D Language Plugin:
  - Syntax highlight *check*
  - Way too many items like writefln, import etc all being marked as unknown. Clearly wrong.
  - ... and nothing else...
  - Socket error (std.socket.xxx) on closing IntelliJ


Conclusion is that it feels like the whole D infrastructure is very, very poorly supported.

Other issues like delays that some of the D plugins seem to introduce:

* Like "loading ..." popups that do nothing but always show up ( Visual Studio Code )
* Like pressing "dot" expecting a response, waiting 2 seconds and then finally something happening ( IntelliJ plugin ) but simply dumping every possible name and variable ( zero intelligent code support )

I assume that this is again broken DCD or Dscanner.

And no, no errors in the console of VSC or anything like that.

Let me summarize my personal D editor experience in the last 1+ year.

* Attempts at getting D editor support going: 6 or 7.
* Amount of times things worked out of the box. One! And this was limited to about a few minutes and after that all suggestions broke again.
* Amount of times dscanner or dcd or other plugins broke because of DMD newest version broke: 4
* Tested on different machines: 4! They all have one thing in common: Windows 10
* Tested on different Windows installations: 3
* Tested on different "version" of Windows 10: 3
* Amount of times complaining to the plugin authors: Too many to count.
* Time spend on these tests / issues: Easily 50 hours or more.
* Frustration level: Again, like each time before EXTREME!

Please do not give me the company line that i need to report issues. I did so many times. It is tiring playing guinea pig, complaining and reporting, waiting for things to get fixed and still seeing things break again or simply not working properly.


I can download Go, C#, C, C++, Delphi, Rust and get proper working plugins for the above mentioned editors but D is always that frustrating problem child. And i can not blame the plugin authors because the issues always seem to stem from the D plugins ( dcd, dscanner, ... ).

Like dscanner changing its binary location between builds from folder root to /bin folder, breaking the plugin authors there system as it expected it in the folder root.

Maybe things work great in a few very specific editor but in my personal experience, D its editor support is non stop frustrating. And i suspect that this complaint is not new.

Clearly there is infrastructure in place for automated testing the compiler but it feels like there is a total lack of infrastructure for everything that surround it. Beyond maybe a few editors that the core team uses?

My personal opinion: Too much in the D landscape is so individualist and not properly cross platform tested, that it results in pure frustration for the end developer.

On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote:
> After months doing a different project, i need a programming language for a new client with specific needs. D comes to mind. As usual that involves downloading the compiler (dmd and ldc).
>
> [...]

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

The DLang ecosystem is getting better and better and you also can help by testing, writing constructive issues or even providing fixes.

Kind regards
André

On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote:
> After months doing a different project, i need a programming language for a new client with specific needs. D comes to mind. As usual that involves downloading the compiler (dmd and ldc).
>
> [...]
>
> My personal opinion: Too much in the D landscape is so individualist and not properly cross platform tested, that it results in pure frustration for the end developer.

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. They are not well supported because they "just" require to have a compiler built in the completion engine. You can also add "auto everywhere" to the problems (plenty of std.algorithm, std.typecons, std.range are not supported at all)

This problem won't be fixed (ever: i'm honnest since i work a bit on dparse dcd etc. i didn't see the "big" thing coming) so the best advice i can give you is "do not to use the things that are not supported by DCD in the public API". Use them for private internal details. And avoid "auto".

Now, let's talk about the bugs. The important things in DCD are done by a library called D-Symbol. This library needs more love. https://github.com/dlang-community/dsymbol/pulls. There are 5 valid bug fixes opened since the end of the summer and that haven't been handled. A movement had started in July / August but apparently has stopped in September for some reasons.

I don't think that complaining about specific editor plugins will help. People who write these plugins have adapted DCD to their product but they cant just sit and wait that the completion gets better. At some point if you work on a IDE you have deal with certain low level language stuff. It's not just about piping process.
(Note: this paragraph is addressed to editor plugins and IDE writers).

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.

On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote:
> 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.

Even one paid developer makes a big difference. You don't need hundreds. Making the problem harder is that many current D users don't have an interest in those tools. Therefore you're drawing from a small pool of part-time volunteer labor.

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

It's entirely up to the community. This is not something Walter or Andrei should be concerned with. I had hoped the D Foundation would lead to a better organization of the community, but to this point, that doesn't seem to be the case.

On Thursday, 25 January 2018 at 21:42:33 UTC, bachmeier wrote:
> Even one paid developer makes a big difference. You don't need hundreds. Making the problem harder is that many current D users don't have an interest in those tools. Therefore you're drawing from a small pool of part-time volunteer labor.
> 
> It's entirely up to the community. This is not something Walter or Andrei should be concerned with. I had hoped the D Foundation would lead to a better organization of the community, but to this point, that doesn't seem to be the case.

It was my impression that D Foundation has sponsoring from different companies. No clue how much but its strange to run a Foundation and not being able to pay one or more full time employees.

I just looked up some community sourced project:

Nim gets on average 1500 to 2000$ per month
Crystal seems to be doing 2000 to 3000$ per month

That is only counting salt.bountrysource and no direct donations.


Just noticed this thread on Reddit and somebody asked about D.

http://www.benfrederickson.com/ranking-programming-languages-by-github-users/

According to the author off the ranking:

18. Rust 0.73%
58. D... 0.047%

No wonder that Rust seems to be more popular and D seems to struggle in popularity.

On Thursday, 25 January 2018 at 21:56:12 UTC, Benny wrote:
> It was my impression that D Foundation has sponsoring from different companies. No clue how much but its strange to run a Foundation and not being able to pay one or more full time employees.

If someone has been hired to work on tooling, I've not heard about it. Based on the number of complaints that should be a priority. I usually work with nothing more than a text editor so it's not an issue for me.

On Thursday, 25 January 2018 at 22:21:18 UTC, bachmeier wrote:
> On Thursday, 25 January 2018 at 21:56:12 UTC, Benny wrote:
>> It was my impression that D Foundation has sponsoring from different companies. No clue how much but its strange to run a Foundation and not being able to pay one or more full time employees.
>
> If someone has been hired to work on tooling, I've not heard about it. Based on the number of complaints that should be a priority. I usually work with nothing more than a text editor so it's not an issue for me.

No one has. The work on tools happens here since 8 months: https://github.com/dlang-community. I was in the team until September and i can say without any doubt that there's no money involved.

I someone is paid for making tools then it's a kind of "Manhattan-project".
So impossible, it would split people and create tensions.

On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote:
> 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.

Curious because based on my own experience, a reasonable D programming style gives reasonable results with DCD. Maybe you missed how to configure things ? For example in CoEdit, everydays deps should be registered there: http://bbasile.github.io/Coedit/widgets_library_manager#description. In addition the dependencies of a DUB  project are automatically handled at level 1 and if already fetched.

I haven't used Delphi (which you mention in your first message) for a while (2012 last time) but even in this big commercial IDE there was a dialog where paths for libs had to be registered. And at this time this dialog was way less friendly than the one i made for CoEdit!

On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote:
> 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.

Well the entirety of what is used in basically every editor was developed by one person. Until recently all those projects were solely maintained by that one person. Rust's compiler can be integrated with tools if I'm not mistaken, at least I know it was being worked on a while back when I looked it up. Comparing to Rust isn't exactly fair, it is a lot more financially well off with Mozilla back it.

When the tools are community run it is going to be like this. No one actually wants to work on it, they would rather be working on their own projects. Not working on tools that make working on their own projects a tiny bit easier. The tools are at a point where they are decent enough to use. You seem to be short tempered, you tried 2 plugins rather quickly, without even trying to see if there were configurations or other options you could use to get features working.

>   - Limited name suggestion ( VSC functionality not the plugin ) only by forcing VSC (ctrl+space).
>  - ... and nothing else...

This is just not true...

https://imgur.com/z6CZbjL.gif