Symmetry Investments pay for at least 2 varying-hours staff for the D Language Foundation - including me. This is a recent development. They are seemingly constantly hiring, too.
D is basically designed not to be risky. The whole language is a big collection of simple compromises for the most part, i.e. if you want to write correct code the obvious thing to do is encourage testing and contracts, surprise surprise D has first class unit tests and Ada style function contracts.
1) D is not dependent on the funding of one big corporation, so our future is not at the mercy of such corporation.
2) Three highly compatible compilers exist, all of them libre. Inclusion into gcc is probably the best insurance for any language.
The D community may be comparatively small, but for us it is big enough. Changes in and around the language may happen comparatively slowly, but for us they happen fast enough. Tooling may be comparatively limited, but we are actually rather impressed by what is available.
The language itself is of course awesome.
It's a tough language to sell to a large organization. When you're a solo developer D gives you the flexibility and freedom to pursue the many different paradigms that it supports and create your own mini-dialect of the language that suits you perfectly. You can sprinkle some garbage collection here if you want, some meta programming there if you'd like, or narrow things down to a barebones strongly typed C-like language. There's a great deal of exploratory freedom in that respect.
When you're in industry, those freedoms can become liabilities because you end up paying the cost of the language supporting things you have no use for. I don't want to pay for D's garbage collector and I don't large teams all writing up elaborate template metaprograms that have to be maintained. If I wanted a garbage collector, then C# or Java is almost certainly the better choice. If metaprogramming is what I want, I'd use a Lisp dialect like Clojure. For any specific feature D has that would be a major selling point or competitive advantage for my company, there's another language that is almost certainly far better suited to providing it. There isn't one single language that does everything D has, but there's also no single project that would want to make use of all those features, and this becomes very apparent when you see how fractured the D community is and how many mini-dialects of the language there are. Do I support GC or not? Do I make it compatible with betterC or not (meaning exception support).
Having a kitchen sink like language results in those kinds of trade-offs. Good language for carving out a niche for yourself that can adapt to your specific style of programming and give you as an individual a great deal of expressive freedom... bad for when you need to coordinate with a large team and buckle down on a small set of rigorous and specialized features that are likely better served by using a tool focused on delivering it.
In practice, you'd be surprised. Some of the things like -betterC were solely developed as a toy, but nearly everything I can think of in D has a use and is useful when used as intended. The people who do use D in industry use those features - this is still 80-20 as with many things in programming, but (for example) first class unit testing is so blindingly obvious you'll miss it when you don't use D.
One of the reasons why you would use D is that you can pick and choose because one day you will (say) hit a performance wall and need inline assembler, then goodbye clojure (for example). Just do what works for your project, the code is a lot harder anyway.
Obviously it's a self-selecting group, but these problems really don't exist all that much when you are actually writing software - libraries, yes, programs not so much.
Most D programs I write use a mix of these technologies.
As for metaprogramming, D is very very good at it.
That said, in principle one could imagine a version of Unity that used D instead of C#, and I think that would be a pretty neat combination.
You would have to weight this choice against existing engines like Unity/Unreal/Godot vs custom. I released a game with custom engine in D once and what really mattered was that there was no market fit (and no sales). Choosing engine vs custom is a question that only exists if people materialize to play your game ; a lot of successful game shops are prototype-heavy or at least advise that strategy.
Side note: I met the creater of D, Walter Bright (also of course famous for the digital mars compiler) at going native 2013 (now known as cppcon). Bright was the nicest guy, and was happy to field my questions. We even chatted about rust, which was just a twinkle at the time!
> digital mars compiler
And the one/s before that, even. He wrote the first proper C++ compiler to my knowledge, and lots of that shows in D.
Some people were also working on a reference counted type (that'd replace the GC I guess?) a few years ago, but I don't know what happened to that, or if it did make into the language. There are a few open RC pull requests from 2019 on the d runtime repository.
Not sure what the current state is.
A lot of people say that, but that's the tip of an iceberg of 500 items that will prevent someone that doesn't want GC from using it. In other words, nobody ever used a language only because it didn't have a GC.
But if we're being reasonable, then I can say me and my company mostly still use C++ because it doesn't have a GC. It's an otherwise horrible language and I'd love to get off it. For a new project making an order matching system for a financial exchange, we are experimenting with Rust as an alternative and it's looking very promising. I want to see a bit more how the async situation plays out because that aspect of the language has me concerned but overall it's a really clean and principled language.
At any rate, the point is that a GC in and of itself is a major deciding factor about whether a language is used or not for many production grade systems.
I wasn't being extreme. I was making a statement based on year after year seeing people make the same claim. After the GC is gone, then it's the legacy C++ code, the lack of documentation, the lack of developers experienced with C++, the tooling, various language issues, and on and on.
The thing is, you can already disable the GC and slap @nogc on your program and you don't have a GC. Or compile with the -betterC flag and you don't have a GC. It's not like D requires using the GC. When you say that, the reply is "Yes, but..." followed by issues using D as @nogc.
> we are experimenting with Rust as an alternative and it's looking very promising. I want to see a bit more how the async situation plays out because that aspect of the language has me concerned but overall it's a really clean and principled language.
This is exactly what I'm talking about. The GC is only one of many reasons you're not using D and probably never will. And that's okay, because if you remove the GC, someone like me will never look twice at the language.
All the rest of your points in your follow up post are very specific to D and yes, those other points are all legitimate reasons people don't use D, regardless of its GC. It's simply that your original claim about language preference on the basis of GC was not specific to D and it's certainly false.
There are some English issues with your post (using a language because it doesn't have a GC is pretty different from quitting a language because it has a GC) so I'm going to let this discussion die.
I don't know what that means
That's a shame, because it is extremely easy to write GC-free code in D. One very important fact is that if you don't allocate using the GC (using "new", appending to a slice, etc.), *the GC will never run*. D provides you a ton of tools to make sure that you're not doing GC allocations, and if you are, where in your code they are happening (@nogc, -vgc and even -betterC).
Yeah, it's not a popular language. Probably won't suddenly take off as one.
But if you like it and you're writing software for yourself, who cares. It has the most practical C++ interop of any language, which may or may not be important to you.
It's got a core community of very active, helpful folk.
Edit: Please with a big grain of salt while I work out whether I'm over-counting, it looks like we've roughly tripled since the last numbers on Andrei's site.
By other measures, like number of committers in open-source projects, it's also small and not growing:
https://www.openhub.net/languages/compare?language_name[]=dm...
GitHub trending struggles to find enough projects to show a full page:
https://github.com/trending/rust?since=weekly https://github.com/trending/d?since=weekly
And of course Golang dwarfs both in popularity. I'm not saying popular is good, but merely answering OP's question about language's growth.
Lots of press lately goes to Go and Rust. I even hear about Zig more than I hear about D these days.
Yet I know of at least one company putting their eggs in the D basket (Weka).
Just curious if anyone else feels like this is kind of risky compared to other more-established options. (obviously chicken and egg issues exist).
Haven’t used D in quite a few years, but I’m thinking about playing around again soon.