4. A lot of criticism around D were outdated. Whenever you search stuff about D you still find people talking about the split, disabling the GC invalidating over half the std lib (this has changed a lot) etc, from years ago and a lot has changed since then
5. The forum is very helpful, and I was able to get my issues fixed without anyone telling me to RTFM or being mean
6. It's about 20 Years old and has some very mature libs (like the gtkD lib)
7. Running D code like a script with RDMD was great for rapidly learning D
8. I think having 3 separate compilers is great! DMD, GDC and LDC2 all have their pros and cons
Cons
1. I found the documentation very difficult to grok. I found it more difficult to understand than Racket's or Rust's
2. It feels like lot of the momentum of D is gone, and has been replaced by rust, zig, etc
3. Lack of examples, lack of questions and answers that aren't from 10 years ago
4. Not a lot of intro materials for people who aren't C/C++ programmers
Overall I liked it. Due to a variety of personal reasons I moved on, but if things don't work out with Rust I might be back. I really don't want to try to learn C++ again, I just don't enjoy it.
They also really know their stuff. I suppose that's an advantage of all less mainstream languages and tools, but D's community is particularly impressive.
Another way of putting it: in the C++ community, the average person on a forum is never going to have a seat on the C++ standards commitee. They'll never even get close. With a smaller community like with D, you can find forum threads where the forum regulars are discussing the future of the language, and the discussion really has weight on D's evolution.
There's at least one company using zig for embedded software, despite its pre-release status, because it's just so much easier to work with than C.
It has a lot of potential. You're not wrong that, at the moment, it's most just potential. But people have noticed, and I think once it does finally stabilize in a year or two, it's going to be a huge for embedded type programming and system libraries that would otherwise be C. The value propositions is pretty huge for those use cases especially.
Recently I got fed up with C++ for good and have no interest in touching it anymore. There's just a sheer amount of complexity and lack of free (as in beer) tooling that has driven me mad these past years until I finally gave up last month.
Then I checked D and I wanted to try it, but couldn't get a Rider/IntellliJ (can't recall) plugin to work, so I also marked it as lack of tooling; I also couldn't find many code examples, either on github or in communities which weren't old-ass forums.
I finally decided to go back to the sanest language I've used, which is C#. With little effort I could get back to writing code instead of endless yak shaving for simple things. For these kind of projects I'm working, a GC isn't the issue, so that didn't bother me. It feels like asking for modern class-based with c-like-syntax and a good std lib in a language is too much... It's sad that C++ "won" the race being such a cumbersome language with slow compile times and a outdated mindset.
I looked at Go but the lack of generics didn't help, so I ditched it. I'm very excited about it now that they're considering adding it though. Thanks for the tip, I'll check out what changed in the meantime!
They may have trippled since that site stopped updating. I'm still working out what we can actually claim as traffic but the unique IP count per day seems to have jumped by quite a bit
> Yet I know of at least one company putting their eggs in the D basket (Weka).
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.
I work for another company also putting its eggs in the D basket (SARC). We do not consider this risky because of two main reasons:
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.
Certainly D has a lot of support for hobbyists and solo developers, but hasn't seen much adoption from industry.
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.
> but there's also no single project that would want to make use of all those features,
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.
Sure, you can find better GC support in languages that are built around GC, and you can find better functional support in languages that are built around FP, better OOP support in everything-is-an-object languages, but what D does is enable one to mix & match GC, FP, Metaprogramming, etc., in the same program.
Most D programs I write use a mix of these technologies.
As for metaprogramming, D is very very good at it.
That's an excellent point actually. I think as a language D could work well for indie games but even there... if you're an indie developer do you go with D or with Unity (which uses C#)?
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.
> if you're an indie developer do you go with D or with Unity (which uses C#)?
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.
Imho, D's choice to be garbage collected has prevented wider adoption (that's the case for my usage at least). And as a compiled gc language, it competes squarely with golang, something that's likely hard to do, given the corporate (google) support golang has.
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!
I like the GC so I don't have to bother with manual memory management. It also a simpler GC which works quite predictably and one could work with it or around it. I hope it stays in the language. One could use @nogc if they don't want it. D's GC is also configurable:
They're replacing a lot of GC'd standard library functions with @nogc functions, so people might not have to depend on the GC soon.
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.
As just one anecdote, the mere presence of a GC made me stop looking at D more or less immediately. In terms of positioning, I think D would be better served focusing on a vertical.
> As just one anecdote, the mere presence of a GC made me stop looking at D more or less immediately.
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.
If you're being absolutely extreme then sure that's true. I'd still use Ruby with it's garbage collector to implement a video game instead of using Brainfuck even though Brainfuck doesn'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.
> If you're being absolutely extreme then sure that's true.
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.
If you had said "No one ever decided not to use D because of the GC" or something along those lines sure... I'd agree. But your claim was "No one ever decided to use any language whatsoever because it didn't have a GC." and that's simply untrue. If C++ got a GC I would immediately stop using it and would have never used it to begin with.
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.
> But your claim was "No one ever decided to use any language whatsoever because it didn't have a GC." and that's simply untrue. If C++ got a GC I would immediately stop using it and would have never used it to begin with.
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.
> As just one anecdote, the mere presence of a GC made me stop looking at D more or less immediately.
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).
Started exploring D recently and my experience has been that the community is a bit isolated but not nonexistent. You can find answers for most questions but most of those will be in the D forum. There are some good books though.
You'll always get a fairly near-immediate answer on the Discord too.
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.
I have the logs for the website downloads, I'll crunch 'em and post them later assuming all goes to plan.
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.
Node.js adds several orders of magnitude more packages as well. That doesn't mean much, other than that a lot of disputable quality packages are added, introducing needless entropy and dependency hell. I compiled a simple Rust program (pueue) a few weeks ago which pulled ~290 deps, which served as a reminder, although nothing broke compared to node and also no deprecation and security warnings. Golang is no different.
And there are orders of magnitude more JS programmers. Not every package on DUB is a gem either. So I think overall it's a reasonable proxy for language popularity.
By other measures, like number of committers in open-source projects, it's also small and not growing:
Tangential to OP's link, I am suprised at how easy creating Windows apps with gtkD is. I figured there would be a lot more steps/configuring/etc. [0: Video link below]
Seems quicker to get started on a new app than Visual Studio + W10 SDK? (or other offical MS Libs) Then again...that's not a high bar when it comes to VS.
I happily replaced my go to scripting habits of using Python with D. Fast, fast, fast — all I can say about its compile times and data crunching capabilities.
C++ always felt like C with the whole kitchen sink, the plumbing system, the neighbourhood sewer system and the county water treatment system thrown in.
Whereas D always felt like an actual evolution of C. D always seems like it fell into a weird place. It's too high level for C people and too low level for higher level programmers. It also had that weird history of starting closed source and only opening after they'd missed the bus so to speak.
Personally, i wish things would have been different. I wish people were posting silly comment memes about too many D related posts on hn rather than rust or golang ones.
The tools D offers and its general philosophy just fits with the way I think about programming. It gives you every tool you need or could want, without getting all Perl on you, gives you the freedom to choose your programming paradigm without imposing one on you, stops you from shooting yourself in the face, but still lets you shoot yourself in the foot if your really, really want to and you tell it to explicitly allow you to.
It's always felt like just a programming language where you can get whatever you want done, in whatever way you sent without hassle...maybe someday...if the community and grew to the point of bigger more popular languages.
I've always felt it to be underrated and for some reason one of those languages people seem to have a strong opinion about, even if they don't know much about it, but in a subtle way where it doesn't get mentioned unless someone brings it up.
We are using D in our laboratory and found that it has been incredibly easy to onboard Python and Go programmers, and they are more productive to boot. We miss the packages /ecosystem libraries of some other languages , but otherwise the experience has been excellent.
Each changelog for the last good handful has seen a lot of work in this area.
I recently had to write and learn a bit of C++ for the first time, and tried at all costs to avoid it (FFI/interop from Rust or D).
I wound up biting the bullet and writing C++ but I learned a lot about FFI in general and how interop works, plus your options available in both languages.
D has this new experimental C++ header generator (which is exciting), plus D has always had:
extern (C++)
Which is capable of directly linking + invoking most C++ things (except constructors/destructors, it can't handle those, you need a function which calls the constructor from within C++) just given a type definition.
Then you have "d++", which lets you "#include" C/C++ headers.
Under the hood tries to run an automatic syntax conversion. It can't handle <std> but for simple code it works and can spit out the equivalent D.
And finally you have the somewhat abandoned (but as far as I know mostly functional) Calypso, which is a fork of the LLVM-based D compiler that supports direct interop with C++. It's a pain to build though, haven't gotten around to trying to build it, but it does look wicked cool:
pragma (cppmap, "cppheader.h"); // tells Clang to parse cppheader.h but do not import anything
import (C++) NamespaceA.Class1; // imports NamespaceA::Class1
import (C++) NamespaceA; // imports the full namespace
import (C++) *; // imports the entire translation unit
So I am hopeful about the future of the relationship between C++ and D. I would really have loved to have not written that C++ lol.
The "Ecosystem Task List" is a good idea https://github.com/dlang/ecotasks. I always thought it would be a good idea to have priority lists for ecosystems so that people know where to focus their efforts to help the community the most.
What would these compilers have as advantage over the existing compilers?
Back when there was just one D compiler the common complaint was that this was too few. Now that there are three you sometimes read that there are too many. This is the first time I see someone needing more :)
The GC is still a key part of the language but it is increasingly only used for things that you wouldn't be able to do without a GC anyway (e.g. if you want to pass a closure anywhere without managing it's lifetime you need some kind of GC).
Avoiding the GC has probably never been easier however, and D is already very good at avoiding the garbage in the first place.
I even work on/for D and I'm not a huge fan of the GC, but it is also the case that these questions pop up on sometimes almost quasi-religious grounds: The GC is just a tool, if it gets in your way it's fairly easy to avoid in the sense that you don't call in, it doesn't stop.
Check out vibe.d and the hunt framework. Both would probably get you started in that direction. Vibe.d is quite powerful and flexible, but might not be the easiest framework to get into. I haven't used hunt yet. Last time I looked, I didn't find any docs in a language that I could read.
From hangin out on Reddit for dlang, the http server is pretty slow. This has caused people to look elsewhere. Some people are trying to improve the performance, but it’s not a high priority.
What is the point of putting that zero in the version number when it quite clearly is not a decimal number and now it kind of looks like one and is confusing?
The more time I spend with Python, the more it seems to me that a language defined abstractly and having multiple implementations (none "official") seems to be the healthiest compared to one with a reference compiler/interpreter. D seems to have one "reference compiler" and just a "reference manual".
You wouldn't have two or more reference compilers -- that would defeat the point. There are three popular D compilers, one of which (DMD) can be considered the reference.
As for "reference manual" -- well, every tool should have a reference manual. The "reference" here has a different connotation. I think you might be conflating "reference manual" with "formal specification", which is not accurate in this case (and in most cases).
The advantage of multiple compilers is that people find subtle differences which humans miss by only reading the spec. Since D has only one frontend, it does not get that benefit although it can technically claim to have three compilers.
I'm not sure how this actually applies to D? There are definitely niggles with how dmd is currently implemented but they are usually quite hard to bump into day to day.
This is a valid criticism; yet a spec is "code" that has to be maintained and created, so in the context of open source someone has to do it. An ISO-quality spec needs a lot of efforts to happen.
Pros
1. It felt very practical.
2. Handling packages using Dub was great
3. The D programming book by Ali Çehreli was a great introduction http://ddili.org/ders/d.en/index.html
4. A lot of criticism around D were outdated. Whenever you search stuff about D you still find people talking about the split, disabling the GC invalidating over half the std lib (this has changed a lot) etc, from years ago and a lot has changed since then
5. The forum is very helpful, and I was able to get my issues fixed without anyone telling me to RTFM or being mean
6. It's about 20 Years old and has some very mature libs (like the gtkD lib)
7. Running D code like a script with RDMD was great for rapidly learning D
8. I think having 3 separate compilers is great! DMD, GDC and LDC2 all have their pros and cons
Cons
1. I found the documentation very difficult to grok. I found it more difficult to understand than Racket's or Rust's
2. It feels like lot of the momentum of D is gone, and has been replaced by rust, zig, etc
3. Lack of examples, lack of questions and answers that aren't from 10 years ago
4. Not a lot of intro materials for people who aren't C/C++ programmers
Overall I liked it. Due to a variety of personal reasons I moved on, but if things don't work out with Rust I might be back. I really don't want to try to learn C++ again, I just don't enjoy it.