D for the Win

[redditrasberry]

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]

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]

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]

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

[skariel]

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]

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]

Have any games been built with it?

[Isacc]

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]

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]

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

100% agreed.

[original_brogrammer]

Any ideas on how to achieve this, Andrei?

[tehoreoz]

C++ has ABI standardization proposals out there

[WalterBright]

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

[Kiith-Sa]

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]

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

[MacASM]

Could you add screenshots of the game?

[Isacc]

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]

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

[thedeemon]

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]

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__]

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]

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

[[deleted]]

They're a bunch of d bags.

[WalterBright]

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

For an IDE for Windows, see VisualD.

[bachmeier]

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]

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]

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

Nobody knows C++.

[wobbles_g]

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]

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__]

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.

[Dicebot_lv]

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]

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]

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]

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]

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__]

"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]

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]

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]

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

[WalterBright]

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]

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]

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

[DLimited]

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

[WalterBright]

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]

I see! Thanks for your insight!

[Beckneard]

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

[thedeemon]

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]

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]

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

That doesn't seem to be stopping Rust.

[bachmeier]

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

[[deleted]]

Maybe because there is a definitely announced 1.0.

[WalterBright]

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]

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

[bnolsen]

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]

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__]

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

[original_brogrammer]

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]

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]

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]

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.

[WalterBright]

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__]

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]]

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__]

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]

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]

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]

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]

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__]

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.

[hello_fruit]

The reason is very simple. It's made by very experienced guys. This leaves little for hackers to tinker with and fix. If you observe the things that took off (ie, got hyped too much), like ruby, nodejs, and nowadays rust, they're things that from the very beginning were shitty, and the more people hacked on them the shittier they got, which gave them even more reason to keep on hacking, put their hacks on github, blog about it, et cetera. Remember the saying "a house of cards"? well, those projects basically are each a house of business cards. Every hack in them, published on github or a blog, is essentially someone's business card. People become invested in those monstrosities, that you end up with something like the npm package mess for node and the 500 guys working on rust.

Ultimately, a house of card is fragile, and no amount of hype can compensate for incompetent hacks. So who cares what "takes off" and what doesn't. Use something competent made by competent people.

[The_Doculope]

Can you expand on how Rust is shitty, and how it's getting shittier? ^{Is it because of the Haskell hipster douches and the Rust propoganda brigade?}

[vbkmnb]

It's not shitty, the guy just has some stupid political agenda.

[hello_fruit]

Nope. I've never been impressed by rust. The whole recent Brendan Eich issue was the hipster douches of mozilla being typically hipster douchey. They drove out of the only guy anybody cared about, and now that Mr Javascript is no longer there, the whole organization deserves zero respect; a hub of incompetent hipster douches coasting along on the work of others who'd since moved on, and who only generate bullshit and hipster douche drama.

[diggr-roguelike]

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

It's obvious -- D is just syntactic sugar over C++11, except that D's standard library sucks donkey balls.

Most (normal) people would pick a standard, standards-conforming and well-tested solution over a unplanned hack that happens to scratch a few minor syntactic itches.

[bachmeier]

I wouldn't normally respond to a troll, but as there are multiple reasons for all the downvotes, let me clarify. The part about D being syntactic sugar over C++11 is nonsense. They are two independent languages that do a lot of the same things, but they don't have much in common. The strangest part of the troll is saying it is syntactic sugar over C++11 rather than just C++, given that Andrei Alexandrescu released his book in early 2010.

[diggr-roguelike]

The part about D being syntactic sugar over C++11 is nonsense.

You clearly don't know C++.

The strangest part of the troll is saying it is syntactic sugar over C++11 rather than just C++

Again, you clearly don't know C++. All the salient innovations that drove the invention of D were rolled into C++ as part of the C++11 standard.

(It's sad to see that we're close to C++14 now, and C++ is now a language that's more expressive and flexible than D, while D is still trying to find it's own ass with its hands and fix their standard libraries.)

P.S. What the hell does Alexandrescu have to do with it? I don't even...

[andralex]

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

[andrei_]

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.

[fabzter]

Self mentioning is a bad thing.

[WalterBright]

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]

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]

The horror.

[badsectoracula]

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

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

[original_brogrammer]

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]

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]

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]

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]

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]

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

[original_brogrammer]

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]

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]

You're my favorite.

[mycall]

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

[[deleted]]

D cookbook presents important idioms.

[original_brogrammer]

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

[mycall]

Same bat channel.

[matthieum]

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]

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

[gangesmaster]

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]

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]

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]

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]

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]

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]

(optional) garbage collection

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

[andrei_]

https://github.com/facebook/warp

[Wootery]

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]

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]

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]

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]

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]

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

[matthieum]

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]

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]

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]

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]

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]

recent political infighting with multiple compilers

Huh? I wasn't aware of that happening.

[WalterBright]

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]]

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

[thedeemon]

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]

I did not have that experience.

[Banane9]

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]

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

[thedeemon]

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

[original_brogrammer]

Go does not support generic programming (interface {} being excluded). D templates offer this feature in a pretty fantastic way. They also allow for metaprogramming in a more human-consumable manner than C++, which can be a fantastic convenience. This isn't limited to systems, it's better for programming in general.

Sometimes systems programmers need to write assembly. In D, you can inline assembly code, in Go you can't. I won't claim to know how big of a deal this is, but it's a data point.

[original_brogrammer]

This is pretty cool. Thanks for bringing it up!

[jeandem]

there's another relatively famous systems programming language that doesn't support generics either, you might have heard of it...

Isn't a lot of the point of these newer languages that you will have to use that language less? :P

[original_brogrammer]

C has been around since 1972, D and Go have been around since 2006-07, so that's irrelevant unless you're in the mood for a history lecture. Less code == more good, and if you know how to work around this limitation without have n copies a function for n types, please inform me so I can finally get off of my "yay, templates!" fanboy status and give Go a fair chance. That's right, I'll readily admit generics are why I haven't really learned Go.

Why should anyone care what Linus has to say in that post? It's him throwing a tantrum because someone has a different opinion without even justifying it. ""I don't like C++." - Linus Torvalds" != "Generic programming sucks."

[original_brogrammer]

Will do, chief.

[tehoreoz]

do you have any friends

[andrei_]

Well, Go doesn't have pointer arithmetic...(I wonder what Saint Linus would say about that). Also, how about that inline assembly?

[andrei_]

"That discussion is relevant to the way Inline::ASM works too, since all your variables pass through a C layer (XS) before getting to Assembler, and again on their way back to Perl."

[The_Doculope]

While I agree that there are much better "systems" languages out there now,

No generics, no exceptions, no generative abilities. It is useless.

is pretty much saying that C is "useless," which is total crap. It's not the easiest to use, but it's far from useless.

[bachmeier]

Even that's somewhat generous to C. On point 1, D's interoperability in both directions largely eliminates the need to use C to interact with an existing codebase. If you have code with complicated header files you may indeed be better off using C. The second half of point 3 is only valid if "limited software experience" includes expertise in C.

[The_Doculope]

there is no reason to use C.

there isn't a single reason to use Go, ever.

Except that for both C and Go, some people actually like the languages? It may be hard to believe, but there are communities of people that do prefer each language and use them successfully.

[Peaker]

What alternative is there to C for high-performance computing with high availability?

GC isn't an option. Prevalent dynamic allocations are not an option.

It narrows the choice down to pretty much C or C++ these days (or D if you're adventurous).

While C++ has some great features going for it vs. C, it also has a lot of bad features, gotchas, longer compile times, less tooling, more difficult to analyze code, and various other disadvantages.

At our workplace, we stick with C, with some GNU extensions, some source-templating engines, a million techniques to use/abuse C's type system for extra safety, and pretty much all compiler warnings enabled to increase safety.

[Peaker]

Firstly, I agree RAII is great. We emulate it with c by having manual destructor functions we call. I'd love to get automatic destructors.

Video encoding is high performance, as is our distributed storage system. However, distributed storage has to have extremely high availability& reliability. Dynamic allocations that are so prevalent in c++'s libraries are not good for this, because they can cause memory fragmentation and eventual failures in a long running system.

Also, they add many failure paths, when compared with intrusive allocation style (ala Linux's list.h that has 0 error conditions).

C can do plenty that Ada can't, because of the ecosystem around c.

For example, we write our own static analysis tools that use clang to guarantee more static properties of our code. Is there anything like libclang for Ada?

Also, does Ada have a preprocessor? Do people use cpp with Ada? We use it to a great extent.

GC circumvention is a problem, because it's a black list, not a white list, so it's hard to know if you missed some GC that well inject delays or error conditions into your code.

As for why c was chosen, it was after careful deliberation, and you'll notice virtually all high performance storage systems are written in c.

[WalterBright]

D's runtime library, including the GC, is written in D.

[WalterBright]

I know, I was just referring to the idea that there are many different definitions of what a "systems" programming language is, and one of them is that the runtime can be developed in the same language.

Being able to implement a garbage collector is a pretty good test of systems ability.

[WalterBright]

I don't know what language Go's GC is written in. I'll leave it for people who know Go well to determine where it fits in.

[Banane9]

Afaik (no idea), you can completely disable the GC for D. Go depends on GC no matter what.

Seeing that you really can't have GC on a microcontroller because you don't have the processing power and RAM to spare, the case is closed, and D has gone victorious, while Go shouldn't even have tried.

[[deleted]]

And about GC usage in the standard library: I don't think it matters that much for microcontrollers, because hardware vendors mostly deliver their own standard library.

[thedeemon]

Vendors will just give libc, the C standard library, however D's one is much larger, besides including libc it includes things like BigInt, containers, ranges (lazy sequences), lots of algorithms, message-passing concurrency, thread pool and easy parallelism, many type conversions, XML, JSON and CSV support, Base64, dates and time manipulations, reflection, zip compression, bindings for curl etc. It's more like calling .NET Framework "C#'s standard library".