D’s Newfangled Name Mangling
dlang.org
dlang.org
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):
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++.
They 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.
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:
void main() @safe
{
int everything = 42;
int* theAnswer = &a;
int* earth = theAnswer * 2; // Won't compile.
}
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++ 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
>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 even a simple pragma), or partially removing it during critical sections, or straight up removing the entire D runtime for embedded purposes. All of which have been completely successful and not "that hard" to do since they're not that coupled together. And lastly, of course, the GC isn't that slow unless you're doing crazy allocations (add one element to an array 100,000 times) and systems programmers don't program like that anyway.
Hell, I still prefer RAII. The GC only kicks in for stuff I don't care about like lambdas/closures, string/array manipulation, and functional algorithms. But I can absolutely use static arrays allocated on the stack with a single line of code. (You can even use malloc for non-GC touched data and alloca for stack allocations). There's no way I could do that in C#.
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:
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.
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.)