As a frequent user and fan of the D programming language, I've noticed a number of misunderstandings and stumbling blocks that frequently trip up newcomers to the D scene.
These are perfectly understandable confusions. Many of them have very legitimate historical causes, so it's unsurprising that certain outdated or inaccurate beliefs persist. I take these as areas where the D community could communicate better to the outside programmer community, so allow me to explain:
- D has IDEs
- DSource is dwindling, but D is more active than ever
- The D1/D2 split is no more
- Phobos is D's standard lib, but what's up with Tango?
- D is open source
- D allows manual memory management
- Static-typed does NOT mean unproductive
D has IDEs
There was a time when D didn't have much IDE support beyond syntax highlighting. This is no longer true. If you like fully-featured IDEs, there are three main options, all of them actively supported:
DSource is dwindling, but D is more active than ever
Every few months, the D community hears something like this: "Is D dead? I went on DSource and everything looked old and unmaintained, the forums seemed inactive, so I assumed D was dying."
DSource was the de-facto project-hosting site for D projects. Note: Was. These days, most of the active projects have moved over to GitHub and BitBucket. In fact, even the repositories for the official D compiler and it's standard library have been hosted on GitHub for well over a year. And in that time, contributions and growth have significantly accelerated, not declined.
There had been updates in the works for DSource to address the issue of easily finding the active projects amongst the dead ones (keep in mind, any free open-source project hosting site is inevitably bound to accumulate many dead projects). But with the incredible recent popularity of GitHub and BitBucket, such an update to DSource would be of minimal value.
It does, however, bother me a bit to say such things about DSource. I've always greatly appreciated DSource, and it was a fantastic thing to have back in the D1 days before GitHub and BitBucket had become everyday names for almost any open-source programmer. The site, bandwidth and hosting were, and still are, very graciously donated to the D community free-of-charge, so I hate to speak of DSource in a manner that sounds like a eulogy. But nonetheless, even though DSource usage is now minimal, D is not only very much alive, it's rapidly growing.
As for finding active D projects, in addition to ordinary search engines, I recommend the D Wiki. Admittedly, we haven't been as good about maintaining the wiki's list of projects as we should have been, but I hereby pledge from now on to do my part, and I'll nag other D users to do the same ;)
UPDATE 2012-12-12: In order to aid and encourage updating, D's wiki has recently moved from http://www.prowiki.org/wiki4d/wiki.cgi to http://wiki.dlang.org, and is now built upon MediaWiki (the same engine used by Wikipedia) instead of the dwindling ProWiki which a number of contributers have found awkward to use. The D community has also taken this opportunity to purge the outdated cruft from the wiki and update it. So D's wiki is indeed progressing!
The D1/D2 split is no more
D2 is where it's at. D2 has already become the stable branch, D1 is a relic. Forget D1, stick a fork in it, it's dead.
And when I say "dead", I don't mean Python 2 "dead": I mean that practically nobody is using D1 anymore. Everyone's already on D2, even the stragglers. D1 is so unused that official support will end at the close of this year, 2012 (and that was announced a year ago). Nobody cares about D1, nobody uses it. It's over.
So, there is no D1/D2 split. There is only D2.
(EDIT: I may have overstated this point. See the comments below.)
Phobos is D's standard lib, but what's up with Tango?
You may have heard about a "Phobos vs Tango" split. In retrospect, that was indeed a misstep for D, but the issue was recognized and fixed. First the summary: Phobos is D's standard lib, period. Tango is now an optional but Phobos-compatible third party library. That's all there is to it.
But that wasn't always the case. Here's the history, for anyone interested:
Back in the early D1-days, back even before Andrei Alexandrescu had come on board, D's standard library "Phobos" was in a very rough, incomplete state. This was because it was being developed entirely by one person (D's creator, Walter Bright). Unfortunately, he was too busy developing the language and compiler to be able to fully flesh-out the standard library (which was, due to various reasons, not entirely open at the time).
So a group of highly talented developers got together and undertook the admirable task of creating a complete standard library. This was called Tango, and it was so good, and so much better than the incomplete (at the time) Phobos, that it became the de-facto standard library.
Unfortunately, in order to work well, Tango needed to replace some of the very-low-level runtime portions of Phobos. This meant Phobos and Tango were incompatible - you had to choose between one or the other, not both. This, quite understandably, became a giant PR disaster.
Meanwhile, Phobos began transitioning to open-source, Andrei Alexandrescu joined up and became Phobos's leader, and Phobos finally started getting fixed and fleshed-out. And it was getting very good in its own right. But this naturally didn't help the "Phobos vs Tango" issue. Admittedly, it may have been a misstep in D's history. But fortunately, the D community heard the "Two standard libs?!?" complaints loud and clear, and set out to fix it.
At this point, D2 was underway as the main "unstable" (at the time) development branch (while D1 had become the stable "non-breaking-changes-only" branch). So for D2, the low-level runtime stuff that was creating incompatibility between Phobos and Tango was factored out and dubbed Druntime. In D2, Phobos and Tango *both* use Druntime, so Phobos and Tango are now fully compatible. There is no more split.
Which should you use? Phobos, unless you have some specific reason to pull in Tango as well. After all, Phobos is the standard library.
Why might you want to use Tango? Same reasons as any other third-party library: If you like the design of it, for example. Tango's design has a very Java-flavor, so Java users may like it. Or if you find something in Tango that's not in Phobos. For example, Tango has the world's fastest XML parser. Phobos's XML library, on the other hand, is the one module in Phobos that's known to still be in desperate need of a rewrite and might get removed. (Don't worry, the rest of Phobos is fantastic.)
D is open source
There are three main D compilers:
- DMD: Official reference compiler
- GDC: Uses GCC and is in the process of being merged into GCC mainline.
- LDC: Uses LLVM.
GDC and LDC are fully open-source, period, and are even in certain Linux package repositories, and not in the non-free sections.
The standard library and runtime, Phobos and Druntime, are OSI-approved Boost-licensed.
DMD's entire source (as well as the standard library and runtime) is publicly available on GitHub. The front-end, which is shared with GDC and LDC is OSI-approved Artistic-licensed (EDIT: It's also dual-licensed under GPL).
The only thing that isn't strictly OSS is the backend of DMD, because the rights are licensed from Symantec. But the source for it is publicly available on GitHub and open for pull requests. Worried about redistribution? Don't be: Just ask Walter. He may be under obligation to require his permission, but it's only a technicality. Ask him, and he'll grant permission. He hasn't been known not to. And note, that's only for DMD, and specifically DMD's backend. Everything else is fully-OSS including two complete D compilers: GDC and LDC.
D is open-source. It wasn't always, but it definitely is now.
D allows manual memory management
D may have a garbage collector as standard, but that doesn't mean you can't control it, stub it or replace it or use manual memory management.
D supports pointers (neatly limited to a memory-safe subset of operations if you're using @safe mode) and calling C functions. So you can call malloc/free, and stick anything you want in the resulting memory using the emplace functions. Or you can use stack-allocated auto-scoped classes. Or reference counting. Or no-clutter RAII. Additionally, there's a whole custom-allocator system in the works.
Static-typed does NOT mean unproductive
D may be static-typed, but that shouldn't make you think "C++ and Java":
% cat funWithRanges.d import std.algorithm; import std.range; import std.stdio; void main() { // All done lazily: auto squares = sequence!((a,n) => n^^2)(0); auto fibonacci = recurrence!((a,n) => a[n-1] + a[n-2])(1, 1); auto fibEven = fibonacci.filter!(x => x%2 == 0)(); foreach(v; zip(squares, fibonacci, fibEven).take(6)) writeln(v[0], "\t", v[1], "\t", v[2]); } % rdmd funWithRanges.d 0 1 2 1 1 8 4 2 34 9 3 144 16 5 610 25 8 2584
And it's not just clean and fast, it's also safe and correct.
Plus there's some nifty concurrent processing toys, easy templates and metaprogramming, and the usual lineup of expected modern niceties.
18 comments for "Dispelling Common D Myths"
Good stuff here, although your statement about D1 is entirely incorrect. We are using D1 for our entire infrastructure, and we are surely the largest company using D commercially (we have offices in 8 countries). Two of us are major contributors to D, our company did most of the testing and patches for the 64bit compiler. I also know other programmers in my city (Berlin) who are using D1 professionally.
In both the D1/D2 issue, and the discussion of the Tango/Phobos split, you're reporting the Andrei version of history, which isn't really correct. A very common D myth is to assume that the newsgroup is representative of the D community. It isn't. Most professional D programmers that I know, have never posted a single message to any of the forums. They might read the announce forum occasionally (to check for compiler releases), but that's all.
Well, the statement about D1 is not entirely correct. I know of a fairly big and growing company that's using D1, the one I work for :)
I think there are a few more users out there, I agree that maybe not enough to keep putting work in maintaining D1, but is still not completely dead.
What will this people do when D1 support is dropped? Who knows... migrating maybe? Maybe maintaining D1 ourselves will be less work than migrating the fairly large D1+Tango codebase?
But just because D1 is forgotten doesn't mean is exactly dead and are no more users out there...
Hehe, I replied to that before reading Don's comment. Of course we both work at the same company :P
So it's 2012. Does DMD output COFF format yet? Guess not. I'll check back in a year.
@Don: If they don't post to the NG then they're not really represented, the community has no other choice than to reach the conclusion that D1 is dead. You could try using back-channels and talk directly to Walter or Andrei to keep D1 alive, but that means wasting Walter's time on working on D1, which is against what the majority of the community wants (they want him to work on D2 exclusively). Saying "some people you've never heard of work on D1 professionally" doesn't mean much at all. D is almost entirely a public community effort, I don't see why we should care about people who aren't part of the community.
Your statement "the newsgroup is not representative of the D community" isn't really true. The NG might not be the representative of the *user base*. But "community" isn't a term for popularity, it actually means something (discussions, contributions, etc). So the fact that your "professional" coworkers never post is just disrespectful at best. D is a community effort, and it all begins on the NG and in the IRC channels. For that matter D1 is dead.
At a time when community involvement is crucially important, why should we care about a deprecated language, used by people who never post, who develop commercial software we'll never use?
Well, I can't talk about other people but I did posted several patches, and I think you should be blind if you think Don doesn't contribute to D. We are both using D1 at work, and this is of public knowledge, some of the patches I submited are even based on D1 code, not D2. i don't participate in the main D NG because for me it has an extremely high noise/signal ratio, it just doesn't worth the time for me, but I actively participate in bug reports, pull requests, the DMD development list, betas and read the announcement NG.
I even wrote a GC that kicked the ass of the current GC, specially concerning to pause times, and I'm almost sure it still does. That GC is integrated into Tango and NEVER got merged in D2, because nobody cared, even when it was one of the most long-standing issues pissing off people that develop applications with some soft-realtime requirements (including game developers, which has always been attracted to D). We are using this GC at work BTW.
So just because you don't look at the complete picture, or ignore people using D1 and contributing (or at least trying to) doesn't mean we don't exist. Is really insulting really.
BTW, I'm not even saying D1 should be still maintained, I almost agree it shouldn't, but that doesn't mean there still no people using it or that is it dead. You are just giving wrong information, and I don't think giving wrong information is the best way to dispel D myths, is just creating new ones.
Luca, was your GC the one that used fork()? I remember thinking it sounded very nice. As I recall it was put on hold because it didn't have a Windows version. (My memory might be wrong or outdated though.)
Which is itself something that annoys me. So many things are put off indefinitely because it isn't perfect in all cases. I can sympathize with a desire for even quality, but really I say we should just take what we can get.
Some additional comments on this over on Reddit:
http://www.reddit.com/r/programming/comments/118y4m/dispelling_common_d_myths/
@Don and Luca: Thanks for the perspective. I guess even I'm not immune to D myths ;)
There are also more comments on the D newsgroup:
http://forum.dlang.org/thread/20121010023850.00002a57@unknown
@guest: The currently-alpha 64-bit Win version uses COFF and the MS linker:
http://forum.dlang.org/thread/k2go8o$rot$1@digitalmars.com?page=2#post-k2iuik:24k27:241:40digitalmars.com
Also, latest status of Win64:
http://forum.dlang.org/thread/k41c2l$27r2$1@digitalmars.com
I like D as a language, but I'm sad to see that "Does not have decent and well maintained GUI bindings" as one of the debunked myths.
Not sure what does it really mean "system language", but it seems that major port of D users do not care for using D as 'general programming language' and writing GUI apps in it. (Ok, I know about GtkD which is mostly one-man show, but QtD & wxD are mostly dead).
Not ready for prime time?
Lots of critics of D complain that it's "not ready for prime time" and has too many bugs to be taken seriously for commercial development.
Would you say D is a serious tool, or are there still major bugs needing to be worked out? Under which circumstances would you choose C++x11 over D?
Luca's GC is the one that uses fork(). I've pushed for switching to it in the past, but as Luca said there hasn't been a lot of support. From a practical perspective, Luca's GC is based on the Tango GC and the Druntime GC has grown a lot since then. This meant that it would have to be brought up to par with the current Druntime GC's feature set for the switch to be feasible. I don't have the time to do this and no one else has picked up the torch. If anyone is interested though, there's a horribly outdated Druntime branch with Luca's GC code in place named CDGC. The only relevant change is the new GC code in /src/gc, so drop that into a new Druntime repository and go from there.
@Fellow Traveler: There are a few areas that still need some polish, but the quality of the D implementation and ecosystem has improved by leaps and bounds every year, and right now, yes, I think it's certainly ready for real world work. In fact I'm already doing so, and so are many people on the D newsgroups. Plus there's the company Don and Luca mentioned above, even though that's D1. I've heard of other companies using it, too.
And I'll say this, too: Even 5 or so years ago, with the issues it had at the time, I still found that using a fundamentally good language like D was well worth occasional stumbling blocks when compared with a rock-solid implementation of a fundamentally limited language. In my experience, it's easier to work around a bug than a missing feature. Of course, that's not to say that I'd characterize the current D as "buggy".
I may not be the best person to compare C++x11 vs D, as I got fed up with C++ ten years ago, so I tend to be fairly critical of it (ex: https://semitwist.com/articles/article/view/top-d-features-i-miss-in-c ). Personally, the only time I would choose C++x11 over D is when I have no choice: Specifically, when writing for a platform where D isn't an option. Right now, D's platform support is like this:
x86_32: Excellent. Only potential issue is false GC pointers, and there's already a fix for that on the way. Also, linking with non-DMC-compiled C/C++ libs on Windows can be tricky (due to OMF vs COFF), but it's entirely doable and there are known solutions.
x86_64: Very good on Posix, with a few caveats. Win64 is early alpha, but rapidly progressing as it's Walter's primary focus ATM. The "OMF vs COFF" linking thing is *not* an issue here (see my reply to "guest").
ARM: Close, but not quite ready. I'm told GDC and LDC are outputting ARM code just fine, but there's still some work to be done with Druntime/Phobos and dealing with OSes like iOS and Android. I'm really salivating at this one as it's the reason I'm using C++ (non-x11, unfortunately) in one of my current projects.
Game consoles: Unfortunately, I don't think there's any D here yet. Unfortunate because I think D would be a fantastic alternative to gamedev's current "C++ with C#". D is both more of a systems language *and* more high-level than C#. And much more modern than C++. I think they're missing a big opportunity here.
16-bit: Never going to happen. (I'm told 16-bit is still occasionally used in embedded systems.)
hi and thanks for the actual blog post ive recently been searching regarding this specific advice online for sum hours these days as a result thanks bddeabgfegdd
..........
Hey Thеre. I fօund your blog uѕing msn. TҺiѕ iss a verʏ well
written article. I'll mɑke sure to bookmark іt ɑnd return to read mor οf
yοur useful info. Thanks foг thee post. I'll certainly return.