It was one of the easiest languages for me to learn, and I felt I was as productive in it as Py/Node (that I've used for years) with only about 2 weeks of playing with D on the side. There's a lot of intuitional things that D gets very right imho, from syntax to the standard lib. Also the generic/template support in D is a real pleasure to work with coming from most other languages I've used.

There's a couple challenges though. D's community for library support isn't as rich when comparing to even newer languages like Go. The other issue is D's runtime gc (which is being slowly removed/reduced) is pretty slow compared to Go, and is similar to Python in performance.

The shame is, on paper, D could replace Py or Node for being a very developer productive language. However, it can't compete with them because it doesn't have the same massive community. It also isn't performant enough to stand out against Go and Rust. So D is sitting in an uncanny valley without a silver bullet to stand out against any one particular audience. In many ways, D reminds me of Plan9. For me personally, it's one of my favorite languages to program in (it "gives me joy"), but I currently only use it for side projects. My hope is in these active projects:

a) D minimizes gc use and makes the gc as fast as Go's, allowing it to complete in the performance [web app] category. Vibe.d performance competing fairly in the top of techempower benchmarks.

b) Rust adds more sugar to improve developer 'ergonomics' and finishes the async additions.

c) Go gets "D like" generics and macros (Shh... I can dream)

Re GC, it is most definitely not being removed. Dependance on it is being reduced (with @nogc) and if you don't allocate from it, it will never trigger.

It was recently made multithreaded for the mark phase (sweep is still single threaded), which for large heap small garbage has made it significantly faster.

There are also fork-based GC's available for linux where the mark and sweep are done by a separate process.

The GC is stop the world so if you care about latency the default is not so great, but there are plenty of groups using D for hard realtime systems with either no use of the GC or the fork based one. Speed wise the default is not too bad.

I'm not a fan of relying only on any single language, so take what I say with a grain of salt, but D comes with a lot that some people wouldn't expect.

It covers a lot of low-level and high-level concepts, and has a decent package manager attached to the ecosystem. (dub).

Which means you can magically do things like:

     #!/usr/bin/env dub
     /+ dub.sdl:
     dependency "vibe-d" version="~>0.8.0"
     +/
     void main()
     {
         import vibe.d;
         listenHTTP(":8080", (req, res) {
             res.writeBody("Hello, World: " ~ req.path);
         });
         runApplication();
     }

Whilst at the same time D also supports a 'betterC' flag so that transferring your low-level code to a language with higher-level support and higher levels of safety is fairly easy.

It has generics, compile-time evaluation, a great FFI story, and a fairly decent ecosystem of packages out there for you to play with. It has threading and multiprocessing and... So on.

I've not fallen down the D rabbit hole entirely, more focused on nim, but both of them can consume and spit out C APIs like nobody's business. See some great C lib you don't want to hack on, but do want to utilize? D should work well. Want to offer your library to the wider family of C-like languages? D can do it.

Walter bright and co. having designed the compiler so well sometimes makes you feel like your running a interpreter instead, so iterating on your code is comfortable as well.

Actually I think D would be helped by removing features and focusing on really refining the existing stuff, especially CTFE which I think is the real selling point of D.

What kind of features do you think should be removed? There were some people on the forums that were in favor of removing any feature that could be reimplemented with templates as a library solution.

TBH, I'd be in support of removing every feature related to C++ interfacing. To interface with C++, you need to become like C++. If you become like C++, people will just use C++. D has spent considerable engineering effort in various areas in chase of a mythical "C++ programmer", but those people seem to be moving to Rust instead.

Removing the C++ interfaces? This would completely break a decent chunk of the compilers of D, no?

betterC, UFCS are both opt in so what's the rationale for breaking a huge amount of library code?

The rationale would be focusing the efforts of the small development community on the important features and having to worry less about breaking existing functionality.

So we remove a bunch of well tested, working language features on the basis of making the community do less work?

UFCS will probably never change, and even it did it's actually a relatively trivial part of the compiler to implement (i.e. Just a change to the grammar and a basic lookup and type check)

>So we remove a bunch of well tested, working language features on the basis of making the community do less work?

No, it's about focusing effort.

Some polls were tried but you will hardly get any agreement on which features to remove.

> CTFE

https://en.wikipedia.org/wiki/Compile_time_function_executio...

Removing what?