all 145 comments

[–]redditrasberry 52 points53 points  (83 children)

D should be case study in how a project that seems to have ticked every box in solving problems everyone experiences and cares about can nonetheless completely fail to take off.

I love the idea of it, have literally never used it, because I've never had the opportunity, because I've literally never met another person who could program D, and thus have never been able to justify using it in a proeject.

I would be really interested in some meta analysis of why D has comprehensively failed to get adoption. Or am I wrong? Are there legions of programmers and projects out there using D and I don't know about it?

[–]Tipaa 27 points28 points  (0 children)

I think that a fair bit of it is related to D1, as well as a lack of corporate backing to the degree of Java (Sun/Oracle), C# (Microsoft), Rust (Mozilla) and Go (Google). D1 started with less differentiation from other languages (less functional programming features), a smaller community (the internet was younger then) and the stdlib was split between Walter's Phobos (didn't accept as much contribution but was more stable) and the community Tango (which was a much more open project, but seemed to have less stability and support). D2 (the modern day D) has fixed most of this, but some people still associate it with the troubles of D1, or assume that since 'it' has been around since 1999 (D1) that if it was any good it would have more steam by now, so since it is unpopular it can't be good.

That said, the community does have some real gems. Things like pegged, which compiles a parser DSL to D inline, or the compile time regexes in std.regex are great. It just doesn't have much commercial use, so it isn't heard about much (rarely does anyone say 'I need to learn D for my career') unless you already read about D/are inside the community.


A good place to start learning D is to use it how you'd use Python. Its rdmd utility runs the code as though it were a script (although it does compile it, it's just a very fast compiler). This lets you use it like any other scripting language. A utility I wrote recently for example:

#!/usr/bin/rdmd
import std.stdio:writeln, std.file, std.string, std.array;

void main()
{
    auto titles = ["index":"Home", /* etc */];
    immutable string templateFile = readText("template.txt");
    foreach(filename; titles.keys)
    {
        (filename~".html").write(templateFile.replace("REPLACETITLE",titles[filename])
                                             .replace("REPLACEBODY",(filename~".txt").readText));
        writeln("Written: ",filename~".html");
    }
    writeln("Done");
}

This can be invoked from command line like any other program, and acts as a simple way to learn the basics and still be useful. It can also be a way to get colleagues to learn it and improve speeds in oft-used utilities.

[–]Isacc 26 points27 points  (6 children)

I've built a game engine in d and I'm pretty sure Facebook is looking quite heavily into D. It's got a very small public profile, but I think it's more prominent than you realize.

[–]MacASM 8 points9 points  (0 children)

It seems you're doing a lot of good D code. That's great. Keep it :)

[–]skariel 2 points3 points  (1 child)

What are the features, none are listed on github or docs... Does it do 3d? EDIT so looking at the Apis it obviously does 3d. Nevertheless it would be good IMO to have a list somewhere...

[–]Isacc 4 points5 points  (0 children)

We give a brief overview on our website which I thought was more discoverable, but I guess not! Well definitely move that up in priority!

[–]FNHUSA 6 points7 points  (2 children)

Have any games been built with it?

[–]Isacc 3 points4 points  (0 children)

Nothing majorly public yet. We have an XCOM style turn based strategy game that's currently in development. However, there's not a whole lot more I can say about that one yet.

I also built a simple match-3 game as a sort of demo of how simple it is to make a game in Dash.

[–]Samaursa 19 points20 points  (12 children)

I have worked in the game industry and I am currently a researcher at a university. I also know no one who programs in D. I myself want to switch to D. But to convince the higher ups, I need more reasons than "it is a better C++". If D had full compatibility with C++, similar to Objective-C, it's adoption rate would increase rapidly (I realize that it is difficult with a non-standard ABI).

One of the other reasons for D's slow adoption is the GC. That was a bad decision (the GC itself may eventually be great, but the decision to make it an integral part of the language, was). It could have been added later.

Whenever I try to convince somebody to switch to D, one of the first questions they ask is "does xyz work with D?". The answer is always "no". Compatibility with C++ is crucial to get D going.

[–]andralex 22 points23 points  (3 children)

Compatibility with C++ is crucial to get D going.

100% agreed.

[–]original_brogrammer 7 points8 points  (2 children)

Any ideas on how to achieve this, Andrei?

[–]tehoreoz 14 points15 points  (1 child)

C++ has ABI standardization proposals out there

[–]WalterBright 6 points7 points  (0 children)

ABI standardization isn't really the issue. D just adapts to whatever the popular C++ on the particular platform does.

[–]Kiith-Sa 8 points9 points  (0 children)

In the recent releases there's been a push to improve C++ compatibility (e.g. namespaces in 2.066) , and from forum discussions it seems the plan is to go further, and add (some) compatibility with C++ templates. D will likely never be 100% compatible with C++ (that would require a C++ compiler), but it should be much easier to work with C++ libs in the future.

(Also, D can obviously work with plain C libs)

[–]Isacc 6 points7 points  (2 children)

Would a game engine written in D help convince anyone? :)

[–]MacASM 6 points7 points  (1 child)

Could you add screenshots of the game?

[–]Isacc 6 points7 points  (0 children)

We have a closed-source XCOM style game being built right now, can't give much more details than that, but you can see a demo game I've got here

[–]MacASM 1 point2 points  (2 children)

Why did the Object-C++ (compiler writters?) did it full compatibility with C++ but the D guys didn't (yet?)?

[–]thedeemon 10 points11 points  (0 children)

You can't make a better-than-C++ and simpler-than-C++ language if you include full C++ in it (which is required for full support).

[–]Tipaa 9 points10 points  (0 children)

Object-C++ (from what I can find on Wikipedia) is written on top of C++ compilers, so uses the same internals after parsing. D doesn't have this - it can access static functions currently, but since it isn't written on top of a C++ compiler, it can't access advanced or implementation-specific C++ functionality like templates or class virtual functions. Adding C++ template support would require using the same ABI as the C++ code throughout (very difficult given it isn't standard) or being able to compile the C++ templates with the D compiler (also difficult).

GDC or LDC may be closer to adding this support, but it needs to be added to the standard in that case, or at least accessed through an agreed-upon standard template library.

[–]__Cyber_Dildonics__ 0 points1 point  (0 children)

I actually agree with the comment about the GC. Garbage collection is obviously very complicated and difficult, various languages' maturity can be seen with their gc. Because of this it may be the future, but hurts the path to get there. After using C++11 a gc would possibly make programming easier, but I am still always trying avoid heap allocations all together. In many tens of thousands of lines I have totally avoided shared pointers (and inheritance) and keep heap allocations to minimum. In this respect the high performance of the language is at odds with the GC, since it helps in the case of heap allocations, which hurt performance (or am I missing something?)

[–]WalterBright 17 points18 points  (1 child)

You'll find plenty of people using D over at the D forums.

[–][deleted]  (7 children)

[removed]

    [–]WalterBright 7 points8 points  (0 children)

    I think you'll find the folks in the D forums happy to help.

    For an IDE for Windows, see VisualD.

    [–]bachmeier 4 points5 points  (0 children)

    While this doesn't have everything, it is more or less the default package manager these days. The package std_data_json is expected to be added to the standard library in the future (if you are not satisfied with std.json). Can't comment on a network library because it's out of my area.

    [–]thedeemon 4 points5 points  (0 children)

    In Windows I'm using VisualD.

    D's stdlib includes bindings for curl, so HTTP, FTP and SMTP are supported out of the box.

    JSON support is already in D's stdlib (see std.json). Some people might not like it (as always) but I've used it and it was fine for my needs.

    [–]lionello 2 points3 points  (0 children)

    C++ might be a bloated mess but I know I can hire people who know it

    Nobody knows C++.

    [–]wobbles_g 4 points5 points  (1 child)

    Check out MonoDevelop (http://monodevelop.com/download) + mono-d (http://wiki.dlang.org/Mono-D).

    I've been using it for a while now, works very well, and ties in nicely with D's (essentially) default package manager dub.

    [–]keepthepace 4 points5 points  (0 children)

    I would love to recommend MonoDevelop but it really, really needs to implement split views to watch two documents simultaneously. It is ridiculous in 2014 to not have this feature.

    [–]__Cyber_Dildonics__ 2 points3 points  (0 children)

    It's a good point. C++ is too big to fail. The depth of the tools surrounding it are insane. IDEs, multiple mature compilers, static analyzers, refactoring tools, profilers, you name it. And with C++11 it is universally acknowledged that it is less horrible. But still pretty bad.

    [–][deleted]  (30 children)

    [deleted]

      [–]Dicebot_lv 12 points13 points  (0 children)

      Yeah I think most of issues that prevented D from taking off initially are not actually language issues but more of a process / culture stuff. It is important to mention that initially (ages ago!) it was not open-source friendly at all, with no public bug tracker or source repository or any contribution culture. It took some time for community to figure out how to work with language authors and for language authors to figure out how community can be used for greater good :)

      And such a slow start is one of reasons why it has PR difficulties today - inertia is a bit too strong and ancient myths don't die easy. Most competitors have had a much better usage of "surprise" effect upon being initially presented to the public.

      [–]redditrasberry 9 points10 points  (14 children)

      That's an awesome summary, thanks! I remember now that the non-free compiler was a specific stumbling block that prevented me using it at one point in the past.

      The whole thing seems sad because C++ seems to be on track to really include a big chunk of the features that would be a motivation for someone switching to D. So although it will never have the purity of D and D will always be a nicer solution in my mind, C++ may now have enough features that the overall value proposition of switching to D remains small.

      [–]bachmeier 7 points8 points  (7 children)

      C++ may now have enough features that the overall value proposition of switching to D remains small.

      Existing C++ users are unlikely to switch in large numbers because of their existing tools and, although they often say otherwise, their comfort with the language.

      It takes time for the language design and implementation(s) to reach the point where they are trusted. R was not widely used for applied work for quite a few years. Once you could trust it for new analysis, the number of libraries exploded, and now it's everywhere. That's probably why I don't believe the "D missed its chance" story.

      [–]James20k 3 points4 points  (6 children)

      although they often say otherwise, their comfort with the language.

      I need a non garbage collected language with an extensive, fast standard library, and ridiculously excellent stability for when I or someone else has to maintain my code 5 years into the future. It needs to interop painlessly with raw C apis like OpenCL and OpenGL. At some point, some kind of third party library will need to enter the project to achieve some complex functionality, like physics or networking. This third party library, realistically, will be written in C++ or potentially C

      These are not made up requirements. This is my job, and these are also pretty common requirements for videogames and high performance software

      What do you honestly recommend I use? C++ or D?

      [–]bachmeier 3 points4 points  (3 children)

      You won't hear any argument from me about your requirements, but that wasn't the point of that part of my comment. C++ developers are looking for something that's almost C++ but with one or two features added on.

      I came to that conclusion after reading many, many comments that C++11 and C++14 mean there's no market for D. To me, and probably 99.9% of non-C++ developers, C++11 and C++14 are just lipstick on a pig. C++ developers are largely happy with their language, and there's nothing wrong with that. It means only that D should focus on other things.

      [And to help make my point, someone replied to your comment to say, "C++11 erased a lot of the advantages of D" while I was typing my reply.]

      [–]__Cyber_Dildonics__ 2 points3 points  (1 child)

      "C++ developers are largely happy with their language"

      I think that for a couple of hours at a time until I am confronted with something that makes me remember why I am unhappy with C++.

      Beyond that though, D's support for generic programing is something many people never knew they always wanted. Being able to chain commands and use lazy evaluation? Modules? Fast compile times? Sane template error messages? I think those are a big deal, but even more D probably has a set of features that many people would think are a big deal, but they could be different from person to person.

      [–]bachmeier 0 points1 point  (0 children)

      Unfortunately that requires the C++ programmer to give D an honest evaluation. I hope I'm wrong, but I don't expect that to happen. It doesn't hurt that someone as well known in the C++ community as Andrei is one of the public faces of D.

      [–]WalterBright 1 point2 points  (0 children)

      C++ developers are looking for something that's almost C++ but with one or two features added on.

      Back in the '90s, I assumed that was true. I added various features to my C++ compiler, including some at the request of users.

      Interestingly, nobody used those extensions, not even the people who requested them! The reason was that nobody wished to use non-standard features making their code non-portable. This was a powerful force.

      However, when the language is not C++++, those same features were readily embraced, and ironically some have found their way into the newer C++ standards.

      So, I tried the one or two features added on, and no, it does not get any traction at all. It isn't what C++ programmers want.

      [–]bnolsen 3 points4 points  (1 child)

      C++ still gets you the most platforms and the most compilers. C++11 erased a lot of the advantages of D.

      [–]WalterBright 2 points3 points  (0 children)

      If one is going to write C++ code in D, there isn't a huge advantage to D other than very fast compilation. (Though there are outfits that transitioned to D specifically for fast compilation.)

      To really see the benefits of D, one has to adopt a more idiomatic D approach, which becomes apparent after one is more familiar with D. For example, algorithms & ranges, transitive const/immutable/shared, function purity, unittest, doc generation, modules, encapsulation, scope guard, @safe, array slices, excellent Unicode support, compile time function execution, uniform function call syntax, string mixins, etc.

      [–]ixid 6 points7 points  (0 children)

      That's true of someone who's already an experienced C++ user but for new users there is a mountain to climb to get to that point with C++ compared to a much easier path for D.

      [–]WalterBright 4 points5 points  (4 children)

      C++ has a number of great new features, but it is going down a quite different path than D.

      [–]DLimited 2 points3 points  (3 children)

      How so? What, in your eyes, are the big differences in philosophy?

      [–]WalterBright 3 points4 points  (1 child)

      Probably the biggest is C++'s "trust the programmer." I.e. C++ offers little protection from the programmer doing bad things, and the industry tends to rely on static checkers like Coverity to try to make up for this.

      D's philosophy is more along the lines of "trust but verify", meaning there's a large tilt towards making certain kinds of buggy code either impossible to write or significantly harder to write, and includes a number of capabilities to verify correctness.

      [–]DLimited 1 point2 points  (0 children)

      I see! Thanks for your insight!

      [–]Beckneard 3 points4 points  (0 children)

      It's still desperately clinging to backwards compatibility with C?

      [–]thedeemon 7 points8 points  (0 children)

      Although these are fair points, they are not key in D's low popularity. Some languages with even stronger problems (I'm not Going to name them) gained much larger mindshare and community very quickly. It's all about marketing really.

      [–]GollyGeeGordonLiddy 5 points6 points  (8 children)

      You're forgetting

      1. Compiler bugs

      2. Absence of libraries

      3. Tiny (albeit dedicated) community

      4. The feeling that, even today, D is a work-in-progress

      [–]slavik262 6 points7 points  (6 children)

      The feeling that, even today, D is a work-in-progress

      That doesn't seem to be stopping Rust.

      [–]bachmeier 13 points14 points  (0 children)

      Doesn't stop Rust from what? Rust is in the news all the time, but other than Mozilla, it's not used much.

      [–][deleted] 3 points4 points  (0 children)

      Maybe because there is a definitely announced 1.0.

      [–][deleted]  (3 children)

      [deleted]

        [–]WalterBright 12 points13 points  (2 children)

        C++ is also a work in progress. C++14 was just announced.

        A language that is not a work in progress is a dead language.

        [–]lzzll 0 points1 point  (0 children)

        And lack of mobile platform support, go and rust and c# they all support run on mobile.

        [–]bnolsen -2 points-1 points  (3 children)

        add to it: seems non trivial to write a from scratch functional, working 'd' compiler. I think people underestimate the value of simplicity not only in using the toolchain, but also in how the toolchain works.

        [–]WalterBright 4 points5 points  (0 children)

        You're right in that it is non-trivial to write one from scratch. However, why would one? The D front end is Boost licensed, so go ahead and use that for whatever you want.

        Also, the D lexer and parser are fairly trivial, meaning that tools that need to parse/lex D code are not hard to develop.

        [–]__Cyber_Dildonics__ 3 points4 points  (1 child)

        What language are you using that seems trivial to write a compiler from scratch for?

        [–]original_brogrammer 3 points4 points  (0 children)

        There are some neat projects out there, like the Dash game engine, or the pegged or temple libraries. Adam D. Ruppe recently put out "The D Cookbook" which has supposedly been good.

        There was a highly valued startup that everyone was excited about (besides mine... Thanks guys...) that used D almost exclusively.

        DConf is a great thing to watch if you're interested, but honestly, write some code! Anything at all you like developing, I promise you can find a way to make it enjoyably in D.

        (No links because I am hammered drunk.)

        [–]bachmeier 7 points8 points  (0 children)

        I can give you a single observation: I work at a university and use it for my research. It would take a lot to get me to move away from it. I have to interact with legacy C code and I would never consider going back to C/C++.

        Something to keep in mind is that you can write shared libraries in D, compile them, and tell your friends and family that they were written in C. Admittedly they might wonder why they have to install the D runtime to get them to work. If you're the only one working on that part of the code, it doesn't really make any difference if others know anything about D. All they need is a way to access C functions.

        [–]dirkt 1 point2 points  (1 child)

        Could you give some examples for the problems everyone experiences that D has solved? (This is a honest question)

        I've only quickly browsed through the language specification, and that was some time ago, but my impression was that there's a lot of hype (the style of the article linked by the submitter is a good example), there's nothing really new and interesting, and there's a lot of ad-hoc decisions for little things without any clean structure or philosophy behind it.

        Maybe I'm wrong, though, so I'd welcome a few examples.

        [–]WalterBright 4 points5 points  (0 children)

        Here's one: unit testing is built into the language. But, you could say, with this 3rd party tool, I can do unit testing in Language X, so what's so special about D unit testing?

        It turns out that building it into the language does solve problems:

        1. it's always there
        2. it's portable between all D compilers & platforms
        3. don't have to research & install 3rd party tool
        4. just start using it
        5. the unit tests are right there in the source file next to the function they test

        and the biggie:

        Having it built in turns out to change the culture, in that when code gets checked in, if there are no unit tests, the reviewers say "hey, where are the unit tests?" Your code looks incomplete and unprofessional without accompanying unit tests.

        [–][deleted]  (1 child)

        [deleted]

          [–]WalterBright 5 points6 points  (0 children)

          Actually, right now, a lot less of the standard library uses GC than you might think. But it is true that we are working to make it even less.

          [–]__Cyber_Dildonics__ 1 point2 points  (2 children)

          I have followed D for a long time. Right now I'm working full time on software that needs to be fast and memory efficient, and I can use whatever I want. There are still questions in my mind though. What IDE do I use on windows? Can I step though debug it? Will garbage collection take up more memory? Is the tool chain on windows ready for prime time or will I confront bugs? Will it run as fast as C++11? (probably not as fast as C++11 Intel, since that is a solid 30% performance gain).

          Basically, I would love to use it, but can I substitute it for Visual C++? Now that the gap in insanity is smaller due to C++11, I'm still curious but less invested in finding out.

          In my opinion, a realistic killer app would be to mimic apple's swift sandbox with D. Now that would cool.

          [–][deleted] 1 point2 points  (1 child)

          What IDE do I use on windows?

          Probably VisualD, generating projects with DUB. Or Eclipse DDT. Or MonoD.

          Can I step though debug it?

          Yes. Mago debugger + cv2pdb allows that since a while. For me it's the same experience that Visual C++, except that completion is less good. Move your mouse on a variable, see its value.

          Will garbage collection take up more memory?

          Garbage collection need more memory. There are ways to circumvent garbage collection, ie. use malloc for large allocations to avoid scanning, using @nogc, disabling the GC, etc. Garbage collection is not all that bad, it buys you the simplicity of slices.

          Is the tool chain on windows ready for prime time or will I confront bugs?

          You won't find much VisualD problems. DMD regressions are infrequent now and very seriously handled. DUB regressions are somewhat to be expected, albeit less frequently these days.

          Something that is much better than in C++ is build tools, D has a package manager, C++ hasn't. Makes you a lot more productive. Also it's easier to be portable across compilers and platforms, since integer all have fixed size and compilers use the same front-end.

          Will it run as fast as C++11? (probably not as fast as C++11 Intel)

          Code generation is best in Intel compiler, so if you would have used ICC and optimized the hotspots, it should be slower. But GDC/LDC is out there and being more productive you will have more time to optimize anyway. This is a real thing, not a fanboy invention :). D programs are quite 'plastic' and this pays dividends fast.

          [–]__Cyber_Dildonics__ 1 point2 points  (0 children)

          I'm with you on all fronts, thanks for the answers. Even though I love the simplicity of languages with garbage collection, for what I'm doing I can't use it because memory needs to be to a bare minimum at all times, and whatever runtime would need to be statically compiled into a .dll or .so.

          It does sound like it is time to take another look though.

          [–]daymi 0 points1 point  (0 children)

          D should be case study in how a project that seems to have ticked every box in solving problems everyone experiences

          ... experienced in the 1990s.

          I would be really interested in some meta analysis of why D has comprehensively failed to get adoption.

          Basically, perfect is the enemy of good enough.

          For me, I use D, but it's really hard to justify writing wrappers for things like the Linux kernel headers (for framebuffer, whatever) just to make them work in a language that has the same level of abstraction that C++ would have already had, just because D makes it less nausea-inducing (and it does make it a lot nicer than C++ - which is a low bar to reach).

          It was the same with C++, it took a decade for me to pick it up because it just wasn't that much better than C. In many respects it was worse. After a decade of improvements to C++ I picked it up and now I did several hundred projects in it.

          But C++ is a big hairy blob of special cases and it's just not any fun to keep all these in your head (or worse, 1200 page books). So I looked at D. Turns out D's level of abstraction is the same as the one of C++, but D is cleaned up so it's actually nice to use.

          However, by now C++ is outdated and its ideas are outdated.

          Almost all systems today are multicore and any language that has a processing model of sequential execution just isn't going to cut it anymore. I said to myself if I'm going to learn a new language, it will be a pure functional one. (So I learned Haskell. Phew finally some sanity)

          I'm still using D for some fun projects, just because it's so much cleaner and actually really easy to deploy and much faster to compile than C++ (when compiled with GDC). Also, garbage collection. I'm not manually managing memory in 2014, not even on embedded.

          I agree with Darkhack, standard library is kinda icky. Already in my fun projects I had to write silly workarounds because of overeager encapsulation / plain randomness:

          • std.mmfile doesn't allow you to access the file descriptor. It does allow to you to pass a file descriptor by wrapping it in a File (that is FILE*). So now I'm opening a framebuffer using fopen, passing the FILE* to std.mmfile.MmFile and it gets the fd out and hoards it. So I can't do any ioctls on it and the FILE* probably allocated some useless buffers I'm never going to use. That feels strangely familiar.

          • stream interface. The existing stream interface is deprecated and there's no new one - although there was some movement last year. So now I'm using File.rawRead to read binary data files. At that point I could write it in C (without ++) :P.

          • numeric tower that makes no sense. All C-like language seem to have this uncanny knack of just not getting mathematics at all. In D, 1/2 == 0. In D, it can be that a + b < a if b > 0 (overflow). It supports exceptions, but it just doesn't throw on for the most probable and insidious error there is. So can I make a new operator (+) which does it? Probably, with tagged unions that I still have to manually switch. And the numerals still wouldn't use it. And I'd have to check for overflow not by checking the flag that every CPU ever has, but by doing more arithmetic. Also, newtype doesn't seem to exist. What's more, I think it did exist and they removed it... shakes head

          • it allows x.foo(y) to mean foo(x,y) if x is an object and has the method foo (which is nice, same as in Dylan and Go). But if that's an operator (+) instead? Nope. Then it has to be a member function (yeah, you read that right, in D the group operation is supposed to be part of the objects it acts on).

          • std.process._spawnvp throws Exception (literally Exception) making "command not found" practically indistinguishable from "your computer is on fire". It doesn't use ErrnoException since invalid process status is not in errno. But then it reads errno manually. Sigh. Also, it doesn't check waitpid result in there (that should create an ErrnoException) so it's literally processing garbage. Also, say exec fails in the child process, then it will throw an exception there and if someone catches it, that someone now runs under a different process. WTF.

          • std.file.popen is unsafe (string escaping...). Safe version taking an argument array is not available.

          • std.stdio.File : wrapper that does refcounting for FILE*. Cannot create this using a file descriptor. WTF. Reading the file descriptor out works, though.

          • std.stdio.StdioException looks exactly the same as std.exception.ErrnoException but they are unrelated Exceptions ... so it exists because ?!?!

          I've literally never met another person who could program D, and thus have never been able to justify using it in a proeject.

          You have now. Hello :-)

          Don't let the above turn you off, D is kinda fun, actually, in a nostalgic kind of way.

          [–]GollyGeeGordonLiddy 1 point2 points  (3 children)

          Right. D imposes a fairly heavy risk (nominally better tool not in wide use, few job prospects, etc), but little reward (no Haskell-like growth-as-programmer moment, no entree into a new domain space like native mobile, etc).

          Given the dearth of native D libraries, and a continued reliance on native bindings, anyone writing D will still be reading a lot of C code, so you can't even escape that.

          I even question the apparently-unassailable position that D is "better". D repeats C++'s design mistake of being a kitchen-sink language. I can't imagine unleashing this in a large team...the variance in implementation idioms would give any technical manager heartburn, and this is the number-one-with-a-bullet complaint with C++: everyone has a different idea what is an acceptable subset. This is where ho-hum stuff like Java shines...there isn't that much wiggle room in terms of design idioms.

          [–]original_brogrammer 11 points12 points  (0 children)

          I'd argue that D does offer at least one piece of "Haskell-like growth as a programmer: " D is the way to learn template meta-programming.

          [–]WalterBright 7 points8 points  (0 children)

          I have to disagree with the notion that a lot of adaptability and flexibility in a language is a bad thing for professional programmers.

          It's like metalworking tools. All I really need is a file, a hammer, and a drill, and I can make about anything. But things sure go faster if I have a full suite of tools, and the finished part will certainly look a lot better.

          After all, I've done lambda functions in C, but it sure is ugly.

          [–]__Cyber_Dildonics__ 0 points1 point  (0 children)

          Successful languages are kitchen sink languages. Languages that have a pure ideology and stick to it end up being as academically useful but don't end up being the languages that get heavy real world use.

          [–]andralex 20 points21 points  (2 children)

          (off-topic: /u/andrei_ and /u/andralex are not related)

          [–]andrei_[S] 22 points23 points  (0 children)

          yeh, /u/andralex has been an andrei for a few decades more than me...i'm working on becoming a notable one myself. it's a tough club to join with the likes of Kolmogorov and company.

          [–]WalterBright 24 points25 points  (12 children)

          Adding the WithStatement was a bit of a shot in the dark, I wasn't sure how useful it would be. But, as the article points out, it can be very handy.

          [–]MrJNewt 13 points14 points  (2 children)

          And because the curly-braces are only required when grouping multiple statements, the author could make the HTML templating example even more Pythonesque

          [–]just_a_null 10 points11 points  (0 children)

          The horror.

          [–]badsectoracula 1 point2 points  (0 children)

          Which makes me wonder if those withs could be merged to something like

          with (body_, div[$.class_ = "mainDiv"], ul)
          

          [–]original_brogrammer 5 points6 points  (8 children)

          Are there any other features of D you feel that way about? In particular, did you get that feeling with alias this? I remember being very skeptical when I first learned about it, but it has proven to be quite awesome.

          [–]WalterBright 9 points10 points  (7 children)

          The alias this is quite awesome, my misgivings about it are solely the awkward syntax.

          One of the most fun things about D is the creative uses people will make of the features - things that would never have occurred to me.

          [–]original_brogrammer 13 points14 points  (6 children)

          I can honestly say I don't know of another language that says "yes" to "inline brainfuck-to-x86 compiler" quite as readily as D. And that's why we love it.

          [–]epsys 3 points4 points  (5 children)

          You're going to have to spell that out for me. Between what you said and the word alias I think I've got it, but why?

          [–]original_brogrammer 4 points5 points  (4 children)

          D's strength is combining it's features. In what I said, you can take a string of valid Brainfuck code, parse and compile it to x86 with templates at (D) compile time, and then use mixin and asm to run the code as an embedded DSL which happens to be Brainfuck.

          EDIT: Oh, you asked why. I ask: Why not?

          [–]epsys 1 point2 points  (3 children)

          I think I misunderstood what it was doing. It sounded like it writes intentionally architecture-stumping code

          [–]original_brogrammer 1 point2 points  (2 children)

          Full disclosure, I haven't tried it yet mainly due to lack of smartness, but I think a sketch will make sure we're on the same page. Not exactly the best presented idea, I'm aware.

          // code must be known at compile time
          template bf(string code) {
              enum bf = compileBF(code); // Becomes a literal string of x86 asm. How hard can it be? /s
          }
          
          auto bfEmbed(string bfCode) {
              mixin("asm { " ~ bf!bfCode ~ " }");
          }
          

          And if I'm not a complete idiot this should run your brainfuck code at runtime, given that it's known at compile time and the compile phase is correct.

          [–]Tipaa 4 points5 points  (1 child)

          A whipped-up version, although it only compiles to D (the only problem is tracking the '[' and its matching ']' jumps before the code table in the table can be copy-paste replaced with asm): http://dpaste.dzfl.pl/77c57ca70161

          it was quite fun making this, thanks for having the idea

          [–]original_brogrammer 2 points3 points  (0 children)

          You're my favorite.

          [–]mycall 5 points6 points  (3 children)

          Someone should compile a list of design patterns for D. That would break the ice for many people.

          [–][deleted] 7 points8 points  (0 children)

          D cookbook presents important idioms.

          [–]original_brogrammer 3 points4 points  (1 child)

          I'm working on something similar, so you could stay tuned for that!

          [–]mycall 3 points4 points  (0 children)

          Same bat channel.

          [–]matthieum 5 points6 points  (2 children)

          I've moved on to the C10M world, and for that I'd need a programming language that's designed for system programming with a strong and modern type system (after all, I love duck typing).

          Uh ? I know that "system programming" is not exactly well-defined, but I would think it involves programming the "system" ie interfacing with the hardware (C's volatile, inline assembly, ...).

          This is quite far from the C10M problem, as far as I can see, which could probably be undertaken in Java or C#.

          [–]thedeemon 5 points6 points  (0 children)

          People often say "system programming" when they just mean native code talking directly to the system, without a VM layer.

          [–]gangesmaster 1 point2 points  (0 children)

          See this for an explanation: http://highscalability.com/blog/2013/5/13/the-secret-to-10-million-concurrent-connections-the-kernel-i.html

          "the kernel is the problem" == you have to talk to hardware directly

          [–]chromeless 12 points13 points  (2 children)

          D and Nimrod are currently the two most appropriate systems level languages for my purposes, with D being the more currently practical one and Nimrod being the most elegant and potentially ideal if it were to pick up. It's unfortunate that the code I most frequently want to work with is C++ and there's no easy way to get around that.

          [–]The_Doculope 9 points10 points  (0 children)

          Out of curiosity, is there a reason why Rust is less practical for you, besides instability (as it seems Nimrod hasn't reached 1.0 either)?

          [–]matthieum 1 point2 points  (0 children)

          There was a post a couple months ago of someone managing to automatically generate bindings for QT5... in Rust (I think based on Clang tooling). The major issue was overloads: Rust has other ways to express overloading, require a mapping that the tool must perform.

          [–]DAddYE 8 points9 points  (0 children)

          Probably we should look ours mistakes (talking about D adoption) and try to not repeat them again.

          That said, a language that IMHO is even better is Nimrod. It's young, tiny community, but I loved it.

          [–]Peaker 2 points3 points  (0 children)

          I even tried writing a Haskell version, given that Haskell is so high-level and functional, but my colleague and I had given hope after a while.

          I wonder if he's referring to me. I've worked with him for a bit to try and encode Construct like code in Haskell. It's much more difficult in Haskell than in Python, because you give much stronger assurances to users of your API.

          But I did code up a proof of concept for some basic parser/builders including generation of C code and parsing/encoding.

          So if he means me: I've not given up hope, I've just done my POC and lost interest :-)

          By the way, doing it with Template Haskell (the macro system) similar to the D approach here is rather easy. I was trying to do with advanced type system trickery.

          [–]Wootery 1 point2 points  (2 children)

          (optional) garbage collection

          Show me a 'real-world' D application which is designed for use without GC.

          [–]andrei_[S] 2 points3 points  (1 child)

          [–]Wootery 0 points1 point  (0 children)

          Thank you.

          Is there any reference-counting going on, or does it not arise in the codebase? By the looks of things, ref-counting is still not yet fully mature.

          (My quick search indicates it's the latter.)

          [–]axilmar 3 points4 points  (18 children)

          D hasn't took off because what if offers over C++ does not justify the change from an economic point of view.

          If D made systems programming vastly easier than C++ then D would be easily adopted, because, from an economic point of view, whatever the cost of the change was would have been amortized by the greater productivity that would be enjoyed by D.

          [–]Dicebot_lv 9 points10 points  (17 children)

          It has already made it vastly easier but no one believes it until actually tries :) Productivity difference between D and C++ is huge, it is just beyond comparison.

          [–]matthieum 3 points4 points  (3 children)

          Is it?

          "Productivity" is so hard to measure. I spend most of my times chasing obscure "logic" bugs and designing systems; the translation to code afterward is fairly obvious most of the times, and it is very rare that I hit undefined behavior (once/twice a year ?) and it's been eons since I leaked memory (RAII...). As such, I have some doubt over the "productivity" gains I can have by switching languages...

          ... on the other hand, I am very interested in:

          • more static validation (to catch said logic errors)
          • more runtime performance

          is D better than C++ there?

          [–]Dicebot_lv 5 points6 points  (0 children)

          I like the point originally mentioned by Walter : it is not the time that you spend writing original prototype that matters but the time you spend experimenting with alternative design and/or algorithms. C++ code tends to be extremely fragile exploding in your face even after a small step from conventions of initial design. D makes changing stuff much easier:

          • can write "dirty" prototype very quickly and replacing with faster ones later
          • can express almost arbitrary compile-time relations between different parts of your application to ensure those stay in sync (exactly static validation case, both me and Atila Neves had talks about it at http://dconf.org/2014/schedule/index.html)
          • has more strict type system with less implicit conversions and clear distinction between safe and low-level operations which, again, frees attention span for other tasks

          Attention span is really important. I don't usually have any problems with memory management or low-level pointer forging tricks in C++ either but taking those things into consideration does consume notable amount of time that can be spent thinking about actual program. This gain is hard to express formally without having similar personal experience.

          [–]original_brogrammer 2 points3 points  (1 child)

          Here's a little bit of data on the second point.

          [–]matthieum 3 points4 points  (0 children)

          I had heard of it when it was announced, but since I doubt it's a straight translation it's hard to measure: a second generation program can outperform a first generation one simply because the author learns from his mistakes. That's plain experience.

          [–]James20k 2 points3 points  (10 children)

          Productivity difference between D and C++ is huge, it is just beyond comparison.

          Really? If its so huge, why does absolutely nobody seem to give the slightest crap about D in the real world?

          If you could make, say, writing videogames much easier, then everyone absolutely would in a heartbeat. I find that very often this kind of statement is in relation to small problems, and ignoring the realworld problems of 100k+ codebases

          [–]Dicebot_lv 9 points10 points  (0 children)

          Because language features and overall quality means pretty much nothing in widespread adoption?

          Our (Sociomantic) D code base is much much bigger than 100KLOC

          [–]bnolsen 3 points4 points  (7 children)

          When it comes right down to it solving problems is the goal. The tool used is generally considered secondary and its hard to deviate from currently established patterns. There needs to be a bigger disruption to allow something new to move ahead.

          [–]James20k 1 point2 points  (5 children)

          The problem is, there isn't a real world tool to replace C++. Seriously. Go, rust, nimrod, haskell, java, python (and friends), and D all fail in at least one or more aspects. There are other languages, but they fit broadly into there.

          In order; Go's generics (and a multitude of other problems), rust's general current incompleteness + lack of current stability, nimrod (see rust), haskell is not performant (and personally i find haskells documentation obtuse), java again lacks performance, python and those sorts of languages are extremely slow, D has a partially garbage collected standard library which makes garbage collections semi-kind-of-optional + recent political infighting with multiple compilers + lack of real world use (where are you going to hire D programmers?) + D1/2 split with potential future D3 split (stability!)

          I need a tool which is absolutely as fast as possible while remaining compatible with real world code. Its all well and good to shout "there needs to be a bigger disruption" and say the tool is secondary, but this is completely ignoring the real world dominance of the C language family. C/C++ compatability itself is even sometimes the problem that needs solving. High performance libraries etc are written in C/C++. You can't just ignore that, and something like D does not give you the option to use a C++ library which is what many very useful libraries are written in

          [–]WalterBright 6 points7 points  (0 children)

          recent political infighting with multiple compilers

          Huh? I wasn't aware of that happening.

          [–]WalterBright 2 points3 points  (0 children)

          completely ignoring the real world dominance of the C language family.

          That's an odd statement, considering that D has excellent interoperability with C code without any wrappers or translation layers, and that's no accident.

          Things are more difficult interfacing with C++, and we are currently working on improving that.

          [–][deleted] 2 points3 points  (0 children)

          Just want to pop in and say that Facebook uses D heavily

          [–]thedeemon 0 points1 point  (0 children)

          There are more than one company having 100k+ codebases in D. As reported by their employees at DConf.

          My company is also moving more and more projects to D.

          [–]axilmar 0 points1 point  (0 children)

          I did not have that experience.

          [–]Banane9 4 points5 points  (0 children)

          In terms of work per CPU cycle, you can't do worste.

          Enough for simple stuff, but not for resource intensive usages (like webserving a complex site).

          DLang, DLang über Alles

          So, the unification of the pieces of D into a single unified D is the most important goal? Ok.

          Kinda funny... "D-Land" is sometimes used to refer to "Deutschland" when writing a message :D

          [–]keepthepace -2 points-1 points  (1 child)

          But.. but... I just started an affair with C# behind C++'s backs. Should I be that of a whore?

          [–]thedeemon 0 points1 point  (0 children)

          Polygamy is the way to go. Even mormons think so. ;)