First of all, please do not repost this on Reddit or any other forum. This is focused for the D community alone to help deal with internal issues and it does not need to be ridiculed as this is a personal opinion.

As some have seen my posting in the past week regarding D, i like to explain my reasoning. I have been looking for the language to use for my next project, one of them was D.

But the choice was more or less between Rust, D and Go. As all 3 offered good multi-platform support ( essential ), fast, low memory usage.

It came down to a list of criteria. I will mostly focus on D and Go as mentioning Rust too much will simply sidetrack the post too much.


D has no default HTTP server. So you need to rely on vibe.d. Vibe.d being a external package that then relies on a few people to maintain it.

D has no future proof HTTP. There is currently no official http2 build in to vibe.d. Test branches do not count ;)

Go is the only one in the short-list that has a default HTTP solution that is well tested by loads of people, is fast ( especially with pre-fork ) and future proof.


When it comes down to anything HTTP related unfortunately D is lagging behind on this part. Especially vibe.d The techempower is just as example.

My own tests show the same performance issues where D at minimum to a un-preforked Go loses over 30% in real life, network tested benchmarks ( not some silly local device benchmarks that most people do ).

It also shows D has a higher CPU usage for the relative lower performance. Pre-forking Go increases the CPU usage but also performance.

All of my own tests are done with LDC ( optimized flags ) not DMD.

Sure, benchmarks are the devils breath but it makes no sense building a application that even with database queries are slow compared to the rest.


DMD is fast, no doubt about it but Go is just instant in my case for the same type of content i need ( Go HTTP vs D vibe.d ).

Other issues in my past with D also did not help, namely the regressions and constant bug-fix releases.

Its time for D to figure out a stable API. Its really bad when one compiles editor plugin code and sees "deprecated function" all over the output.

How up to date is the even?

Community / Code examples:

D has a nice community here on the forum but out in the real world "the internet" D is more or less non existing.

Google searches end up so many times back to this forum with a LOT of outdated code going back 5+ years, what does not work anymore as API changes happened.

The fact that a lot of code out there is old or non functional is a issue. Worse when 80% of the search results end up in this forum, showing that D does not have a very broad community.

I do not deny that D is used by some big companies as a C++ replacement but the impression is that those are mostly closed source projects where very few code surfaces on the web.

Package support:

Again ... D has very few packages and a LOT of them are frankly so old that they do not work properly anymore with the current DMD versions. Deprecated functions galore.

If D had 1195 active, well supported high quality packages but it has not. Most packages at best have one decent package and that is it.

You want to produce PDFs? fpdf 2015-Apr-06, a very limited PDF generation tool last updated 3 years go.

You want to produce Excel's? Excel-d but it faces the same issue as being the only native project. What if the author ...

GRPC? Imap? ...

As i post this is down so no more comparing. *sigh* < missing Excel-d

Just looking on Github for D vs Go packages. 323 vs 15,351 (dlang vs golang) ... This is again related to popularity and community. So there is much more chance for finding something exotic as a base project in Go then ever in D.

Windows support:

But unlike D, Go's Windows support is simply better.

Plugins work out of the box with VSC. It has its own Jetbrain IDE.

Is Go perfect, no...

Dealing with Gopath is stupid. Who's idiotic idea that was instead of managing simply by project location.

Its no fun dealing with the Go Sqlite plugin ( what is 3th party ) on Windows but then your are in actual production doing something, not fighting D to get your IDE working. Or fighting dub versions when LDC and DMD are both installed and in the environment path.

The amount of strange issues, not bugs or cross platform support issue that crosses D Windows users, simply leaves a bad taste.

Windows / Community issues:

From a persona point of view, its tiring with some people looking down on the fact that i use Windows and have true issues related to D. That have been reported and helped fix but its a never ending stream of fixing one thing, running into another. Currently need to fall back to D 77.1 because of "issues".

But let me say this:

D has a nice community IF you fit into the mold. As a Windows user i am frankly fed up with people giving responses as "report it, fix it yourself" when it has been clearly stated that i do as much.

Or when a opinion is voiced about potential improvements, it comes down to "do it yourself or pay for it".

It is my personal opinion that:

* Do it yourself
* Pay for it
* Report it ( when the author has stated that they did )

Those comments add nothing to any discussions, they sidetrack discussion and only alienate people. Just do a google search and its horrible how many posts show up with this type of comment or variation.

Some people feel overly aggressive in defending D from criticism that it only alienates people. It has alienated me. Whenever i think about D, it positive feeling to move forward is always matched with dread thinking about some people or comments when i want to talk about issues.

The nice people here do not way up, to the people with a chip on there shoulder, that just ruin your day/mood.

It also does not help when comments boil down how "windows users do not contribute" when they actually do. Its very condescending and just scares away people.

At times i think that D is better served as a language with just a blog / news sections, a every expanding ( and up-to date ) examples section and better documentation and no forum at all.


I am personally confused with D's message.

* Are you targeting C++ developers?

From my perspective most seem to be plenty happy with C++ 17. And they have the whole massive tooling, debugging and IDE support already. Given D its tooling, IDE and other issues, you really expect to draw developers away?

* Are you targeting Script language developers?

Missing HTTP solution, no easy CGI solution, .. it feels like there is much missing in terms of convincing for what script language developers are used too.

* Are you targeting C developers?

Sure BetterC is a way towards that but again, what do you offer more then Rust? I see C developers more going for Rust then D on this point. Or hell even Zig or Jai or whatever 3 letter flavor of the month language.

* Are you targeting people new to programming?

From my perspective it does not even look like people with a lacking in programming skills are even welcome here. Everything is build around the idea of people with previous higher level programming skills. Discussions about ideas that tend to be so complex that anybody without a higher level programming background will simply say: "No, do not understand a darn thing" and they look for easier solutions.

* Are you targeting Go, Crystal or new language developers?


What is D even targeting? The kitchen and sink? It feels like D does not even know who its targeting. In my opinion the focus seems to be with C++ developers with most not giving a darn about D.

Go knows its not a system programming language, the focus is clearly more normal and web development. Even Rust has a much more clear message.

Other languages have slogans, they have selling points.

When i hear Go, you hear uniformal, fast, simple syntax language.
When i hear Rust, you hear safe, manual memory management.
When i hear D, you hear ... ... ... ...


D has a lot of advantages like CTFE, Generics, betterC etc over Go. But the resources seem to be spread so much over so much code, that information about how to properly use those Technics is spread thin.

As some wise people said in the past, use the tools you need for a project. And being a jack of all trades but master of non is not good.

It makes D its learning curve also much higher.


In case people are interested, a personal list with 40 points that mattered to me. Each with a score ( Bad 1, Mediocre 2, Good 3 ). As a way to create a impartial opinion just based upon my own needs.

75. Go
69. .Net
67. Rust
64. Pascal < This one surprised even me.
63. Crystal
60. D
55. Swift
51. Kotlin

60/D < Yes, it also came as a surprise. The issues like finding potential affordable employees ( or high training times ), the non existing default HTTP support, lack of packages, the lack of code and examples. And a lot of mediocre (2) scores really made D lower ranked then i expected. I gave every language as much leeway without overly focusing on one specific bad point. .Net ended up high but it was never a contender because of the memory usage, but it was still fairly judge on all other points. Same with Pascal ( talk about a surprise ).

The amount of issues that plague D go beyond the few i mentioned here and frankly will take years with a lot of manpower ( that D lacks ) to even sort out. I think D really missed the boat years ago because if it had a influx of people maybe 10 years ago, it will have been a whole different ballgame now.

Is Go perfect? Hell no ... but one needs to way the positive and negative. And to me it feels like Go has made more positive decisions that actually help people develop, then D on doing too much everywhere. Go is here to stay for the foreseeable future, where as D... not sure and that is scary.

I can go on about a whole lot of technical issue and be told how uninformed i am. There is nothing to gain going down that route as the non-technical issues really put a dampener on D already.

I am sure there will be lots of opinions regarding this post but its suffice to say that my decision to go with Go ( no pun intended ) is finally. I hope this final post is some indication of the issues that have plagued my decision process.

Reply via email to