There are download stats for dmd, the reference compiler[1]. Anyone doing production work is probably using gdc or ldc though so that's not the whole picture.
If you look at the various language rankings (taken with a mountain of salt) D is still fairly low overall. Definitely one of the higher languages without a corporate/industry backer though.
D is an interesting case study for good technology somehow not succeeding. The people working on it are very good and it's a really interesting language. In theory it should slowly have taken over from C++ but for whatever reason this didn't happen.
To some extent, I'm inclined to ask what you mean by success. It's a great language, it has three compilers, it's making progress, and it's possible to have fun writing fast, correct code quickly. It's been more successful than any other language as far as I'm concerned.
Most likely you are asking why it hasn't seen widespread usage in the enterprise (like half of C++'s usage). That's a very high standard. Cost-benefit analysis usually leads to using established languages because there are benefits. D doesn't even have a very good IDE situation (I've been told), only recently got a package manager, etc.
No, OP got it right. D had a shot at success while C++'s standardization process remained stagnant, and D could pick up the slack as it wasn't bound by backward compatibility requirements or the need to update a standard. Once ISO 14882:2011 was approved and C++'s standardization effort gathered speed, D lost the only competitive advantage and lost its chance at relevance.
D is not dead. It is steadily growing. Not as fast as Rust for example, but still healthy.
I agree that there was a nice opportunity before C++11. Now D is lurking in the shadows for another opportunity and slowly building.
I believe D would be a great language for startups because it gives you options. You can do it quicky and dirty (like Python/Ruby/Perl), you can do it fast (like C/C++), you can do it safe (like Java, but not quite Rust), you can be generic and multi-paradigm (like C++), you can be easy (like Python).
While C++ standardisation hay have gathered momentum, it still has enormous inertia (c.f static if, modules, ranges, attributes that were proposed for C++ that either failed to get in or are nowhere near as useful. I can't make do without any of those). The agility of D by by comparison is one of its greatest strengths.
> While C++ standardisation hay have gathered momentum, it still has enormous inertia
That's pretty much irrelevant. The last couple of standards already updated C++ so that it covered all aspects that were deal-breakers decisions on whether to pick up C++ or any alternative whose selling point was being an updated C++. After C++11 (and now C++17) no one in their right mind would decide to rewrite a whole project because of static ifs.
Moreover the irrelevance of D is the only reason why it's trivial to reinvent D when it suits anyone's fancy. A committee of experts deciding on what goes into a standard is not the same as a developer deciding on a whim on what he might implement next. If D was relevant and it's adoption motivated an ISO standard to coordinate which features went into any implementation then I seriously doubt that it would do better than C++.
I would strongly recommend you browse and maybe contribute in the Dlang forum https://forum.dlang.org/ , to build your own opinion, the forum is very friendly and welcoming for beginners
Some of the prevailing opinions on why D didn't succeed
- Garbage collection, D has a GC, and for a very long time it seem to have been positioning itself as a C++ replacement, having a GC, seem to have hurt D more than it benefited it, in this regard
- D vs D2, the current Dlang is actually as I understand D2, moving to a new version that is not fully backward compatible seem to have at least in the past scared away some possible adopters, this seem to be no longer the case, there is only one D now, and this might be a case when lack of popularity was helpful
- licensing issues, I really dont know much about this, but there was some licensing issue surrounding the main D lang implementation DMD, which was also resolved recently
The above 3 points, are what I would call the "prevailing opinions"
Two of them are now fully resolved and only the first one GC , is a work in progress ... once its resolved, and it seems they are working on it ... there will be no excuses
What I personally believe, after lurking in their forum for a while
- D, doesnt have a good product owner, it lacks vision, and it have no competitive advantage
- Walter Bright and Andrei Alexandrescu, are super smart developers, but in my humble opinion ... very bad Product Owners, and just to support my opinion, before anyone gets angry at me ... we all agree D is not popular, so ... this is just a statement of the obvious
- Strategic advantage is a key word here, D have none, and again, the Strategic is a key word here, even if some will list for you the advantages of D, none of them is Strategic
With all I have said, dont let this stop from learning D, I do plan to learn more of it, and while I don't see D taking over from C++, Go, OCaml or Python ... I think it might be a good tool for small teams, who don't want to be fragmented across many languages
To me it seems like there are three broad categories of applications one would use D to implement; network services (ie servers), gui apps, and "other" such as compilers or command line tools. IMO go has won for writing servers; it's incredibly compelling, it has it all (except generics, as someone will surely interject); crypto, ships with easy to use protocol impls (ie http, websocket, etc). The gui lib story for D isn't clear to me at all. Are there bindings to gkt or qt for example? Maybe someone can respond here about that. That leaves "other" which, sure, D seems like a great option.
You forgot the one for which D is best suited: scientific/numerical computing. It produces fast code, it is used by small teams/single developers, it integrates well with C, and much of the work is interactive, requiring fast compilation times.
I think part of the problem is that D isn't as good as Python for scientific/numerical computing, and that people doing Python for it will typically drop to C++ when they need that last boost.
I think a big part was the licensing issue. Before April 2017, the official compiler back-end was some non-open-source license (dunno which). In this day and age I couldn't see using a compiler that wasn't free software. But now that's been fixed --- the reference compiler is now all Boost licensed, and GDC (the GCC front-end) has even been officially accepted into GCC (woot!).
Also, I'm not sure how long the standard package repository and module installer (dub) has been around. But that's here now too.
I think the future of D looks very bright. I'm still learning, but to me D seems somewhat similar to Python, except:
* it's compiled to native code instead of interpreted
* it's syntax uses curlies/semis instead of whitespace
* it's statically typed (but has type inference so you can type many variables as just "auto" and the type is inferred)
Anyhow, very much enjoying D so far. :) I expect D's popularity to grow as more people desire a statically-typed, compiled language, with the convenience of a GC and easy access to native (C) libraries.
I do not believe that it is really a technical problem. While there are arguments to be made (not safe by default, garbage collection, lacking IDE support, ...) these are not killer arguments. In many cases, D has more advantages than disadvantages.
Lack of manpower is a problem. Only Walter Bright and Andrei Alexandrescu work full-time on D. The rest is volunteers. This means development proceeds very slowly compared to Go or Rust. On the other hand, maybe it is more a symptom than the problem.
Perception is a big part. Even in this discussion you can see people remember the "dual standard library problem" which was solved a decade ago. Maybe D just needs a good PR team.
Maybe it is just not a good technology. Just compare it to others:
C++ - memory unsafe, no GC.
Java - memory safe (by default), has GC.
Rust - memory safe (by default), no GC.
D - memory unsafe (by default), has GC.
Authors of Java solved memory safety by adding garbage collector. Authors of Rust managed to make memory safe language without GC while authors of D made a language with GC that is still memory unsafe.
With no flag or @system, safety is not ensured. Using @trusted will allow a function to be called, safe or not, from other safe functions ending the safety. But by design @safe functions can only call other @safe functions.
Yes, D picked the wrong default. That is just a minor annoyance though.
Add "@safe:" to the top of all source files. Check for that in your CI. You are safe now.
The advantage is that you ignore the issue initially. No fighting the type system like in Rust, but easy coding like in Python. Later, when you need your code to be reliable, add annotations and fix problems with compiler guidance.
The reason D isn't popular is simple and not a fault of the language itself. It's one of marketting.
- Go is backed by Google.
- Rust is backed by Mozilla.
- C# is backed my Microsoft.
- D is backed by... D users... and the two language architects.
A few schools use it. A few companies use it.(::cough::This little company called Facebook::Cough::)
The other is target market. D appeals to a new, or more advanced kind of programmer. A new niche or category. A programmer that doesn't get produced at most colleges, or demanded by most companies. And if they're not produced or demanded, that category isn't going to fill up with programmers. Nobody would have used Java if schools across the nation didn't tell kids that "Java was cool" and the JVM wasn't something to be afraid of.
There are categories of programmers. No one can say that a LISP programmer is quite like a C programmer.
- C programmers want "nicer assembler." C.
- C++ programmers don't want a GC. (Though D is working toward a GC-less standard lib.)
- Python/Java/C# programmers are (more likely to be) afraid of systems languages that can segfault like crazy if you don't know what you're doing.
D appeals to programmers who aren't afraid of the entire stack. They write, understand or at least appreciate assembler and caches, while also dabble in high-level templates and functional programming.
I can absolutely say I've grown as a programmer after looking through D features and going, "Why don't I know how that works?"
The guys behind D are brilliant, and professional. Watch any of their talks. Andrei Alexandrescu works for Facebook and still writes plenty of C++. He also wrote THE quintessential "Modern C++ Design" book on template meta-programming. And Walter Bright has been writing compilers for decades.
This is not a toy language.
Here's plenty of benchmarks showing D as fast as (and sometimes beating) C/C++ _and_ having low memory usage.
Meanwhile, the benchmark is misleading. Because not only is generally as fast as C/C++, but it's way more productive to write in.
But back to adoption. It's simple. 1) No corporate backers pushing it, 2) A language for advanced/multi-talented programmers is either scary or "unnecessary" to single-talented programmers.
Most C programmers are afraid of, or think templates are unnecessary. Most C++ programmers are afraid of a garbage collector (even if it's a completely deterministic one that only fires off during specific allocation points).
As a mostly C++ programmer, I was apprehensive of D's GC. But the more I read, the more confident I've been, and, I've had zero actual problems with it. I'm pushing 130 FPS on my netbook just fine, and because D isn't a toy language, I can easily move to static pools and have zero GC allocations.
Well, I would venture that there was much less competition back then and fit a very important middle ground. Per wikia:
>Stroustrup found that Simula had features that were very helpful for large software development, but the language was too slow for practical use, while BCPL was fast but too low-level to be suitable for large software development.
And C++ was also created at the same place as C... Bell Laboratories so (while I wasn't alive then) I think people saw "the next product" coming from Bell and were interested in the next C upgrade--an extension to a product they were already widely using.
C++ use
Date estimated number of users
Oct 1979 1
Oct 1980 16
Oct 1981 38
Oct 1982 85
Oct 1983 ??+2 (no Cpre count)
Oct 1984 ??+50 (no Cpre count)
Oct 1985 500
Oct 1986 2,000
Oct 1987 4,000
Oct 1988 15,000
Oct 1989 50,000
Oct 1990 150,000
Oct 1991 400,000
C++ appears to be similar to D in terms of users, until corporate backers (AT&T!) came online and started pushing it with "traditional marketing", over that of e-mails and newsgroups.
>electronic communication played a crucial role in this. In the early years most distribution and all
support was done using email and relatively early on newsgroups dedicated to C++ were created
(not at the initiative of Bell Labs employees) that allowed a wider dissemination of information
about the language, techniques, and the current state of tools. These days this is fairly ordinary,
but in 1981 it was relatively new. I think that only the spread of Interlisp over the Arpanet provides
a contemporary parallel.
Later, more conventional forms of communication and marketing arose. After AT&T released
Cfront 1.0 some resellers, notably Glockenspiel in Ireland and their US distributor Oasys (later
part of Green Hills) started some minimal advertising in 1986, and when independently developed
C++ compilers such as Oregon Software’s C++ Compiler (developed by Mike Ball at TauMetric
Software in San Diego) and Zortech’s C++ Compiler (developed by Walter Bright in Seattle)
appeared ‘C++’ became a common sight in ads (from about 1988).
Also, trivia piece: "Zortech's C++ Compiler, developed by Walter Bright in Seatle." That's the same Walter Bright who designed D. He also was the creator of a very popular mainframe game from the 1970's called Empire.
D also had a couple of "smears" or "growing pains" that pushed some people away. D was originally a closed-source language that pushed many in the FOSS community away. Then, the standard library was lagging in progress so the community made their own "Tango". But eventually Phobos (the main stdlib) overtook it and now everyone uses only that. However, during that time "two stdlibs" split the already small community and duplicated efforts. The last "smear" I can think of is the garbage collector which gives C/C++ and other system programmers pause because it's a fear of the unknown and the GC hasn't been "proven" with dozens of shipped commercial applications.
On the plus side: The GC is completely deterministic with when it will fire off, and people have been working to remove the GC (as it's not actually TIED to the language, but the stdlib. As opposed to say, C#, which IIRC, would be IMPOSSIBLE to use without a GC.) There are plenty of articles online with people removing GC (it's ev...
UNIX vendors adopted it as sister language to C, given its origins at AT&T.
All C compiler vendors for MS-DOS adopted it. Borland ported their Turbo Vision framework from Turbo Pascal to C++.
Apple gave up to pressure from external devs and moved from Object Pascal to C and C++ with PowerPlant framework.
On OS/2 and Windows it became the language to write GUIs. Harcore C devs would stick to the low level APIs, whereas we would use CSet++, OWL, VCL, MFC.
On UNIX CORBA started to get adoption, and no sane person would use it in pure C.
Likewise we had COM and DCOM on Windows, and SOM on OS/2.
Currently, about as many as those who use Rust, although going by hype, Rust seems to be getting a lot more attention (i.e. larger derivative of the usage curve, perhaps?). If you look at usage on github, there's quite a bit of D code for such a niche language.
I've been doing Advent of Code in D, and I'm having a blast:
I particularly enjoyed doing day 18, which required doing message-passing concurrency (or at least simulating it) and D's concurrency primitives fit the problem like a glove:
How do you get these numbers? To be clear, I'm not saying you're wrong, it's just that this is really hard to do, and I'm always curious how other people do it.
I freakin' love it. I could write pages about each of the features I use and how applicable they are.
C++ is (literally) around a decade behind D, and takes the best features D already had... for ten years or longer. Better templates. Modules. Unit testing built in. Universal function call syntax. And tons more.
I use almost all of those features every day.
It's not perfect, there "are" flaws. But nothing horrific.
It's also "C++ + 1" so any C/C++/variant programmer can pick it up over a weekend.
I genuinely "enjoy" writing D code now instead of all the boilerplate C++ comes with. Things are progressing and eventually I'm going to release a game to Steam with D.
I feel like D would fight with Go in the realm of things I'd use it for, in which case I'd pick it.
On the other hand, D supports a lot of great C++-style stuff, but I'd never pick it in that regime because it'd be the same amount of effort without as-fast-as-possible.
It is also possible for D to be as fast as C++ in many domains: we have LDC based on LLVM for optimisation (parity with clang), but I think that one of the biggest things is the flexibility to have (and determine what is) an efficient architecture.
> it'd be the same amount of effort without as-fast-as-possible.
While the first part is perhaps somewhat subjective, the second is just wrong. D allows you to get to the same bare-metal, no-holds-barred level of performance that C++ does – I wonder where that misconception would come from.
Note that this is not just an academic possibility, but there are real-world use(r)s of D in exactly that domain, for example the folks at Weka.IO for their distributed file system. Of course, their sub-millisecond latencies don't leave much room for careless use of the garbage collector. But being careful about memory allocations for that sort of application is just as sensible a thing to do in D as it is in C++.
I've used D some, for small command-line utilities. It has some good features.
For anyone who wants to get an idea of what D is like, there are example programs on the dlang.org site. Rosetta Code will be another good site for examples.
Also, some of my D programs are online here (a few of the posts are not about D code per se, the others are):
I don't understand why mangled symbol compression is needed. Sure, you need to demangle it for debugging and such, but... all you need is a lookup table, and then you can just hash them down. Yeah, then you need that extra metadata, but with mangled symbols you have it anyways. Hashing + lookup seems much less error prone.
Because the pathological case was IIRC exponential in length range.chain.opertion.length and idiomatically D's `n` in those chain length is very large, sometimes large enough to crash `nm`. The compiler based on LLVM does support hashing the trailing portion of the symbol.
There are some advantages to having access to a human-readable representation for the symbol name, for example because not every piece of binary tooling out there necessarily also supports reading debug info for the target platform in question.
However, another benefit of this is simply that even if you can hash a huge string down to a fixed length, you still need to construct your huge string in the first place during compilation.
With D generally being quick to compile, by the time your symbol names were in the megabytes, all the string creation and manipulation could take up an appreciable fraction of the total compile time. (No kidding – I was quite surprised to see this show up on the profiles as well.)
47 comments
[ 3.1 ms ] story [ 61.1 ms ] threadThey have an orgs using D page: https://dlang.org/orgs-using-d.html
If you look at the various language rankings (taken with a mountain of salt) D is still fairly low overall. Definitely one of the higher languages without a corporate/industry backer though.
1. http://erdani.com/d/downloads.daily.png
https://dlang.org/orgs-using-d.html
However the development is mostly community driven, there is no big sponsor around, like other more widespread languages.
Don't you mean "why it has not succeeded yet?"
To some extent, I'm inclined to ask what you mean by success. It's a great language, it has three compilers, it's making progress, and it's possible to have fun writing fast, correct code quickly. It's been more successful than any other language as far as I'm concerned.
Most likely you are asking why it hasn't seen widespread usage in the enterprise (like half of C++'s usage). That's a very high standard. Cost-benefit analysis usually leads to using established languages because there are benefits. D doesn't even have a very good IDE situation (I've been told), only recently got a package manager, etc.
No, OP got it right. D had a shot at success while C++'s standardization process remained stagnant, and D could pick up the slack as it wasn't bound by backward compatibility requirements or the need to update a standard. Once ISO 14882:2011 was approved and C++'s standardization effort gathered speed, D lost the only competitive advantage and lost its chance at relevance.
I agree that there was a nice opportunity before C++11. Now D is lurking in the shadows for another opportunity and slowly building.
I believe D would be a great language for startups because it gives you options. You can do it quicky and dirty (like Python/Ruby/Perl), you can do it fast (like C/C++), you can do it safe (like Java, but not quite Rust), you can be generic and multi-paradigm (like C++), you can be easy (like Python).
That's pretty much irrelevant. The last couple of standards already updated C++ so that it covered all aspects that were deal-breakers decisions on whether to pick up C++ or any alternative whose selling point was being an updated C++. After C++11 (and now C++17) no one in their right mind would decide to rewrite a whole project because of static ifs.
Moreover the irrelevance of D is the only reason why it's trivial to reinvent D when it suits anyone's fancy. A committee of experts deciding on what goes into a standard is not the same as a developer deciding on a whim on what he might implement next. If D was relevant and it's adoption motivated an ISO standard to coordinate which features went into any implementation then I seriously doubt that it would do better than C++.
Some of the prevailing opinions on why D didn't succeed
- Garbage collection, D has a GC, and for a very long time it seem to have been positioning itself as a C++ replacement, having a GC, seem to have hurt D more than it benefited it, in this regard
- D vs D2, the current Dlang is actually as I understand D2, moving to a new version that is not fully backward compatible seem to have at least in the past scared away some possible adopters, this seem to be no longer the case, there is only one D now, and this might be a case when lack of popularity was helpful
- licensing issues, I really dont know much about this, but there was some licensing issue surrounding the main D lang implementation DMD, which was also resolved recently
The above 3 points, are what I would call the "prevailing opinions"
Two of them are now fully resolved and only the first one GC , is a work in progress ... once its resolved, and it seems they are working on it ... there will be no excuses
What I personally believe, after lurking in their forum for a while
- D, doesnt have a good product owner, it lacks vision, and it have no competitive advantage
- Walter Bright and Andrei Alexandrescu, are super smart developers, but in my humble opinion ... very bad Product Owners, and just to support my opinion, before anyone gets angry at me ... we all agree D is not popular, so ... this is just a statement of the obvious
- Strategic advantage is a key word here, D have none, and again, the Strategic is a key word here, even if some will list for you the advantages of D, none of them is Strategic
With all I have said, dont let this stop from learning D, I do plan to learn more of it, and while I don't see D taking over from C++, Go, OCaml or Python ... I think it might be a good tool for small teams, who don't want to be fragmented across many languages
and there is DlangGUI https://github.com/buggins/dlangui
and for web development check vibe.d http://vibed.org/
I realize that some hold that opinion but I and many others don't.
> people doing Python for it will typically drop to C++
That's something you don't need to do if using D. It's also the biggest selling point of Julia.
Current state: https://wiki.dlang.org/IDEs
Also, I'm not sure how long the standard package repository and module installer (dub) has been around. But that's here now too.
I think the future of D looks very bright. I'm still learning, but to me D seems somewhat similar to Python, except:
* it's compiled to native code instead of interpreted
* it's syntax uses curlies/semis instead of whitespace
* it's statically typed (but has type inference so you can type many variables as just "auto" and the type is inferred)
* it has [dub](https://code.dlang.org/) instead of the [cheeseshop](https://cheeseshop.python.org) (of course, the cheeseshop is currently much larger)
Anyhow, very much enjoying D so far. :) I expect D's popularity to grow as more people desire a statically-typed, compiled language, with the convenience of a GC and easy access to native (C) libraries.
I do not believe that it is really a technical problem. While there are arguments to be made (not safe by default, garbage collection, lacking IDE support, ...) these are not killer arguments. In many cases, D has more advantages than disadvantages.
Lack of manpower is a problem. Only Walter Bright and Andrei Alexandrescu work full-time on D. The rest is volunteers. This means development proceeds very slowly compared to Go or Rust. On the other hand, maybe it is more a symptom than the problem.
Perception is a big part. Even in this discussion you can see people remember the "dual standard library problem" which was solved a decade ago. Maybe D just needs a good PR team.
C++ - memory unsafe, no GC.
Java - memory safe (by default), has GC.
Rust - memory safe (by default), no GC.
D - memory unsafe (by default), has GC.
Authors of Java solved memory safety by adding garbage collector. Authors of Rust managed to make memory safe language without GC while authors of D made a language with GC that is still memory unsafe.
If you wrote every method using the @safe flag, you'd be forced to write a memory-safe program. Eg:
With no flag or @system, safety is not ensured. Using @trusted will allow a function to be called, safe or not, from other safe functions ending the safety. But by design @safe functions can only call other @safe functions.Add "@safe:" to the top of all source files. Check for that in your CI. You are safe now.
The advantage is that you ignore the issue initially. No fighting the type system like in Rust, but easy coding like in Python. Later, when you need your code to be reliable, add annotations and fix problems with compiler guidance.
- Go is backed by Google.
- Rust is backed by Mozilla.
- C# is backed my Microsoft.
- D is backed by... D users... and the two language architects.
A few schools use it. A few companies use it.(::cough::This little company called Facebook::Cough::)
The other is target market. D appeals to a new, or more advanced kind of programmer. A new niche or category. A programmer that doesn't get produced at most colleges, or demanded by most companies. And if they're not produced or demanded, that category isn't going to fill up with programmers. Nobody would have used Java if schools across the nation didn't tell kids that "Java was cool" and the JVM wasn't something to be afraid of.
There are categories of programmers. No one can say that a LISP programmer is quite like a C programmer.
- C programmers want "nicer assembler." C.
- C++ programmers don't want a GC. (Though D is working toward a GC-less standard lib.)
- Python/Java/C# programmers are (more likely to be) afraid of systems languages that can segfault like crazy if you don't know what you're doing.
D appeals to programmers who aren't afraid of the entire stack. They write, understand or at least appreciate assembler and caches, while also dabble in high-level templates and functional programming.
I can absolutely say I've grown as a programmer after looking through D features and going, "Why don't I know how that works?"
The guys behind D are brilliant, and professional. Watch any of their talks. Andrei Alexandrescu works for Facebook and still writes plenty of C++. He also wrote THE quintessential "Modern C++ Design" book on template meta-programming. And Walter Bright has been writing compilers for decades.
This is not a toy language.
Here's plenty of benchmarks showing D as fast as (and sometimes beating) C/C++ _and_ having low memory usage.
https://github.com/kostya/benchmarks
Meanwhile, the benchmark is misleading. Because not only is generally as fast as C/C++, but it's way more productive to write in.
But back to adoption. It's simple. 1) No corporate backers pushing it, 2) A language for advanced/multi-talented programmers is either scary or "unnecessary" to single-talented programmers.
Most C programmers are afraid of, or think templates are unnecessary. Most C++ programmers are afraid of a garbage collector (even if it's a completely deterministic one that only fires off during specific allocation points).
As a mostly C++ programmer, I was apprehensive of D's GC. But the more I read, the more confident I've been, and, I've had zero actual problems with it. I'm pushing 130 FPS on my netbook just fine, and because D isn't a toy language, I can easily move to static pools and have zero GC allocations.
How did Stroustrup get C++ popularized? It's pretty phenomenal that it got so popular.
>Stroustrup found that Simula had features that were very helpful for large software development, but the language was too slow for practical use, while BCPL was fast but too low-level to be suitable for large software development.
And C++ was also created at the same place as C... Bell Laboratories so (while I wasn't alive then) I think people saw "the next product" coming from Bell and were interested in the next C upgrade--an extension to a product they were already widely using.
https://en.wikipedia.org/wiki/C%2B%2B#History
[edit] I found a great, large PDF that details LOTS of C++ history.
http://www.stroustrup.com/hopl2.pdf
C++ appears to be similar to D in terms of users, until corporate backers (AT&T!) came online and started pushing it with "traditional marketing", over that of e-mails and newsgroups.>electronic communication played a crucial role in this. In the early years most distribution and all support was done using email and relatively early on newsgroups dedicated to C++ were created (not at the initiative of Bell Labs employees) that allowed a wider dissemination of information about the language, techniques, and the current state of tools. These days this is fairly ordinary, but in 1981 it was relatively new. I think that only the spread of Interlisp over the Arpanet provides a contemporary parallel. Later, more conventional forms of communication and marketing arose. After AT&T released Cfront 1.0 some resellers, notably Glockenspiel in Ireland and their US distributor Oasys (later part of Green Hills) started some minimal advertising in 1986, and when independently developed C++ compilers such as Oregon Software’s C++ Compiler (developed by Mike Ball at TauMetric Software in San Diego) and Zortech’s C++ Compiler (developed by Walter Bright in Seattle) appeared ‘C++’ became a common sight in ads (from about 1988).
Also, trivia piece: "Zortech's C++ Compiler, developed by Walter Bright in Seatle." That's the same Walter Bright who designed D. He also was the creator of a very popular mainframe game from the 1970's called Empire.
https://en.wikipedia.org/wiki/Walter_Bright
D also had a couple of "smears" or "growing pains" that pushed some people away. D was originally a closed-source language that pushed many in the FOSS community away. Then, the standard library was lagging in progress so the community made their own "Tango". But eventually Phobos (the main stdlib) overtook it and now everyone uses only that. However, during that time "two stdlibs" split the already small community and duplicated efforts. The last "smear" I can think of is the garbage collector which gives C/C++ and other system programmers pause because it's a fear of the unknown and the GC hasn't been "proven" with dozens of shipped commercial applications.
On the plus side: The GC is completely deterministic with when it will fire off, and people have been working to remove the GC (as it's not actually TIED to the language, but the stdlib. As opposed to say, C#, which IIRC, would be IMPOSSIBLE to use without a GC.) There are plenty of articles online with people removing GC (it's ev...
All C compiler vendors for MS-DOS adopted it. Borland ported their Turbo Vision framework from Turbo Pascal to C++.
Apple gave up to pressure from external devs and moved from Object Pascal to C and C++ with PowerPlant framework.
On OS/2 and Windows it became the language to write GUIs. Harcore C devs would stick to the low level APIs, whereas we would use CSet++, OWL, VCL, MFC.
On UNIX CORBA started to get adoption, and no sane person would use it in pure C.
Likewise we had COM and DCOM on Windows, and SOM on OS/2.
I've been doing Advent of Code in D, and I'm having a blast:
http://inversethought.com/hg/aoc/file/tip/2017/
I particularly enjoyed doing day 18, which required doing message-passing concurrency (or at least simulating it) and D's concurrency primitives fit the problem like a glove:
http://inversethought.com/hg/aoc/file/tip/2017/day18.d
How do you get these numbers? To be clear, I'm not saying you're wrong, it's just that this is really hard to do, and I'm always curious how other people do it.
Hm, although I think my estimate is already outdated? It seems like Rust has picked up a lot of steam in the past six months or so.
GitHut.info
Carlo Zapponi 2014
So yes, very outdated. I wish they kept this up-to-date! It's one of the more interesting metrics.
This one seems up to date
C++ is (literally) around a decade behind D, and takes the best features D already had... for ten years or longer. Better templates. Modules. Unit testing built in. Universal function call syntax. And tons more.
I use almost all of those features every day.
It's not perfect, there "are" flaws. But nothing horrific.
It's also "C++ + 1" so any C/C++/variant programmer can pick it up over a weekend.
I genuinely "enjoy" writing D code now instead of all the boilerplate C++ comes with. Things are progressing and eventually I'm going to release a game to Steam with D.
On the other hand, D supports a lot of great C++-style stuff, but I'd never pick it in that regime because it'd be the same amount of effort without as-fast-as-possible.
It is also possible for D to be as fast as C++ in many domains: we have LDC based on LLVM for optimisation (parity with clang), but I think that one of the biggest things is the flexibility to have (and determine what is) an efficient architecture.
While the first part is perhaps somewhat subjective, the second is just wrong. D allows you to get to the same bare-metal, no-holds-barred level of performance that C++ does – I wonder where that misconception would come from.
Note that this is not just an academic possibility, but there are real-world use(r)s of D in exactly that domain, for example the folks at Weka.IO for their distributed file system. Of course, their sub-millisecond latencies don't leave much room for careless use of the garbage collector. But being careful about memory allocations for that sort of application is just as sensible a thing to do in D as it is in C++.
For anyone who wants to get an idea of what D is like, there are example programs on the dlang.org site. Rosetta Code will be another good site for examples.
Also, some of my D programs are online here (a few of the posts are not about D code per se, the others are):
https://jugad2.blogspot.in/search/label/DLang
You also need symbol names for linking.
However, another benefit of this is simply that even if you can hash a huge string down to a fixed length, you still need to construct your huge string in the first place during compilation.
With D generally being quick to compile, by the time your symbol names were in the megabytes, all the string creation and manipulation could take up an appreciable fraction of the total compile time. (No kidding – I was quite surprised to see this show up on the profiles as well.)