I haven't used it in awhile. I was quite positive on it during the D1 days when it was basically C#/Java but AoT. (I don't think Go even existed at that time).

The mess that were the competing stdlibs and the transition to D2 made me lose interest. I've looked at it again from time to time and it just feels too... big. It does too much.

I can get what I wanted from the D1 days with C# AoT now (it also has too many features but they have more obvious use cases and it has a much larger ecosystem).

I really don't see much use in a C++ but saner and with a GC. I'm sure someone has that use case, but not me particularly. And for the "statically typed high-level language with a GC" Java, C# and Go can do it with massively larger ecosystems backing them up.

There might be a future in the BetterC D subset or if they find a way to go after the Rust market with a more C++-like language but even for that I'm a lot more bullish on Herb Sutter's cppfront.

I honestly don't know what they can do to get a breakthrough. Walter Bright is appropriately named and there's a lot to like in D, it's just lacking a direction and an audience IMO.

I use D for a game

What i like:

- fast to compile

- C like syntax

- modules

- slices

- metaprogramming

- compile time type introspection

- independent devs

What i don't like:

- maintainers seems to run in circle, they are scared to improve the language therefore they do nothing to improve it

- no vision

- they no longer seem to view D as a system language

- lacks features to enjoy D as a true "betterC" language

D is nice if you like C but hate headers, they unfortunately chased high level languages for too long, and it shows (EH and GC), language became depend on the two too much, making them unable to capture the system programmers

What's sad is even the high-level languages managed to catch up, as you've mentioned with Go, C# NativeAOT and Java's GraalVM

Web Assembly for example, to target it you have to create a object.d and copy paste bunch of Type Info and hooks... it's been like that for years and they didn't bother improving it, how can you be taken seriously.. system side of things got neglected

Then you have the allocator API that still is marked 'experimental', you can't ignore Exception Handling for your errors

Years after years, whenever you try to mention those issues, they always find ways to either ignore or to remind you that you should fix things yourself

Overall D is a nice language, there are much better languages if you want to target system level stuff, and there are much better languages if you want to target high level stuff

The fact that people mention using D instead of Python is just sad.. relegated as a mere alternative to an interpreted language

The language lacks leadership, it needs a reboot, 3rd time is the charm, just like Python right? ;)

I wanted to play around with Dlang a couple of times. But the few times I've tried, it was quite a hassle to setup a dev environment to start with my preferred tooling. Some concrete points:

- the Dlang plugin for the JetBrain suite (Clion) is quite limited and requires the dmd compiler

- the dmd compiler is not in Debian...

- for dmd you have to manually download .debs and hoping to pick a compatible version

- dub, ldc and gdc are in Debian but then don't mix & match nicely with the external dmd

I know these are all just tiny issues, but they add up...

Something else is the organization of the standard library, which is a bit confusing. Why is std.complex not in std.math? Why std.ascii, std.utf not in std.encoding? curl is in, but socket is toplevel? I don't understand this organization principles.

I've previously used it a couple of times, I've used it to build webapps (using vibe.d) and plain binaries.

It's a fun language but very big. What I mean by a big language is that the syntax is very large.

Its very flexible, you can meta-program a lot in it and its easy to fall into that.

What I enjoyed the most with D was how easy it was to get started AND to prototype! Really, D could be treated as a scripting language to quickly test your ideas. And when you're ready, you can scale D into a large sized project.

I mentioned in a previous thread that the BetterC flag is a pretty cool feature that some C / C++ programmers might enjoy.

What did I not enjoy with D you might ask? The error logs or stacktrace could be too verbose and confusing, I was (and still am?) junior to writing low-level code. And last time I used D was like 4 years ago, and I remember back then when I stumbled upon issues or errors I could not figure out the cause of, it was fustrating.

I use D and like it. For me its positives are:

- Much faster than Python (I use it in my day job).

- Not as flexible as Python (not much is) but its so flexible I've yet to be hindered by it.

- GC-based which has let me build complex libraries quickly without being buried in memory management.

- Large standard library with rich documentation.

- It's easy to build libraries and executables (programs are organized in directories).

- Works on macOS, Windows, and Linux.

- Supported by a plugin in IntelliJ IDEA.

- Welcoming, responsive, and active community forums.

- Write low- and high-level code in the same language.

What I don't like:

- The library ecosystem isn't as expansive as you'd find in languages like Python and C#.

- Sometimes feature additions get mired in community discussions.

I started using D after the move to D2 and only heard about the move in HN comments. Day-to-day it has never been an issue.

You can get many of the positives I list in languages like C#, F#, and Go. I think the community in D kept me from going elsewhere.

Edited for formatting.

I have tried to keep up with Dlang, and even wrote some projects on my home server in the last number of years. I do like Dlang and see potential behind it.

However, the problem I have with it is lack of LTS (long term support) releases. DUB, its main package repository, has a number of decent libraries available. Sadly, each library are likely build/released on the latest version at that time. So each package can be built on different versions of the compiler. New compiler releases have been known to break something, so it is off putting to create a project in D that might, say, include a number of DUB packages.

^^ Please note that LTS has been addressed due to complaint about (another) breaking code changes from a user/poster.

This is why I have only used D for 'small projects' on my server that requires no DUB dependencies. I have tried component programming and other things but, in the end, just cannot get a handle that what I am doing really is "better" than just writing it in C. This is where I think DasBetterC peaks my interest. Of course, if you use D with no GC (which you can disable) - a lot of the features D has is no longer supported. This, to me, throws out DUB.. as it can be difficult to reason if this package is doing functional, or OOP, or whatever combination it is doing... and sometimes you might need to care about memory.

To backtrack, I have always been on the lookout for the "perfect" language... one that can be used for 97% of problems.. daemons, web, gui, etc. Personally, I just want a "Better C" language that covers these areas. It comes down to these:-

- DasBetterC - Rust - Zig - Odin

At time of writing, Odin is one I am keeping an eye on. It is not trying to cram "this cool feature" for the sake of doing so. They have set the grounds on what they will and wont do with the language. Ie No classes, not GC, no "Exception handling" etc.

   I do like having the control, and yet Odin still seems enjoyable to code in - from my experience so far.
I like it, use it, and teach it.

- It's both fast for prototyping and also scales well for large applications.

- Compiles very fast with DMD and supports many platforms with LDC and GDC.

- CTFE (compile-time function execution) is a big win.

- standard library has enough of the common things (json, sql, csv, curl, sockets, etc.) that I need for my domain. Other stuff I can usually find a package or C library to read in if needed.

- most of the defaults seem right to me in the language versus C++ (variable initialization, struct as value type by default, explicit casting, module system, thread-local data, etc.)

Ecosystem does need a boost but I think that's actively developing, so code-d plugin for VSCode is a good place for most to start (I prefer VIM). Ecosystem seems to be slowly and steadily growing otherwise.

I can post links to more video tutorials if useful (disclaimer: I made them :) ).

I never used D-lang in any production application.

But for an IOT prototype where the executable size and performance were very important we benchmarked D also along with Go and C#.NET Core.

I made the same prototype in Go, C#, Java(GraalVM Native Compile) and D-lang. The results were surprisingly positive for D-lang.

Best Peformance -> D-lang, next Go and then Java(GraalVM), C#.NET Core.

Executable Size -> D-lang:500kb, Go: 2.5 MB, C# : 11MB, Java(GraalVM):8MB.

Our major concern with D-lang was lack of dependable(tested) standard libraries.

It doesn’t really answer your question, but DConf was a fews ago and there are a lot of interesting talks there:

The recordings are on YouTube with time stamps to each talk.

D accompanies you from prototype to production (with graduate enforceble constraints) so I find it very flexible and practical, and the highlights of my programming career tend to be in D. If you want native with a joyful creative process, D is a good match.
I absolutely love D’s contracts with pre and postconditions. These I can simulate in other languages however. The invariant is where D really shines imo. Also the fact that you can overwrite the r value constructor, move constructor and cooy constructor are great ideas and the static function support is also good!
I learnt D (D1 to be precise) out of curiosity in... 2005 or 2006. At that time, there's only 1 compiler: DMD (no GDC/LDC yet), and there was the tango/phobos fragmentation. I think my intention at that time was looking for a "better C++" alternative.

These days, for system programming Rust is gaining much attention. And if you don't need such low-level control and can happily live in GC-land, probably Go/Nim suits you better.

Well, I'm not a C++ coder (mostly code in Java/Kotlin). Not sure how I'm going to use D these days...

I am a big fan of systems languages with automatic memory management, and love how expressive D happens to be.

D is what Go would have been, if its designers cared for programming language history.

Still use it occasionally on hobby projects.

What I don't like is the lack of direction, changing the next big thing that might bring people in, without fully stabilising the previous attempts.

Thus making D lose its edge over other alternatives.

When I went looking to ditch java after learning about ptrs and cpu caches, D won out over C/C++ for being multi paradiam and having a GC (wasnt in the mood to learn manual memory mangment yet). It has kept its primarlly used language status however due to its meta programing capablities(mixins std.traits, staticif staticforeach, CTFE..). The only other systems langague I'm aware of that can beat D in this regard is JAI. So if anyone knows of any others I'd be intrested to hear.
I've tried it every so often over the years because I love what it was trying to do. Tragically, I think it might have been really successful if it just had optional GC/runtime from the beginning so it could stick to displacing C++ instead of competing with all the other fancy managed languages. Ultimately, C++ got a lot of ameliorating features to make it feel more like D and D had a lot of half-baked additions that made it feel more like C++.
I love D; unfortunately, since I use Qt, I'm mainly limited to C++ for a lot of personal projects. With that being said, I strive to use D where I can, and my most recent project is making use of some neat D features (like C++ interop).
I use it at work. It's pretty nice! If you write in a functional style, it's very high-level while still retaining that C-like comfort of familiarity. And the metaprogramming is top-tier.
cant make a fully static build:

Thanks to all who replied, guys. Interesting points made.
i used it years ago. it solved nothing for me despite being cool. i've not seen any interesting developments in that direction.

but then i still consider java, c#, go, rust, haskell pointess badly designed and built clusterfucks, so what do i know?