30

I've been eagerly learning D language these last days. It looks like a dream for me as a supporter of several millions lines of C++ code. We support heavy performance low latency system and it is clear that C++ was the only option in the last ten years. Now, I see D.

So, my questions are pretty obvious. Can I start thinking about migration commercial software product to D language? Is there any example of such migration or existing big commercial software product written on D from the scratch?

How is it safe to invest in this language now? Do we have production quality compiler and debugger? Can we assume that they will be supported and developed?

If you have any experience in migration from C++ to D, it would be great to hear about it from you.

PS. By D I mean D2

Thank you

peterhil
  • 1,536
  • 1
  • 11
  • 18
Stas
  • 11,571
  • 9
  • 40
  • 58
  • 2
    Note that D uses a stop-the-world garbage collector, which may be incompatible with your goals for developing low-latency systems. – Vladimir Panteleev Jun 18 '11 at 12:40
  • 5
    @CyberShadow: [GC can be deactivated](http://stackoverflow.com/q/472133/11343) – CharlesB Jun 18 '11 at 12:42
  • +1 but should be on [programmers.se] – CharlesB Jun 18 '11 at 12:42
  • 3
    If you globally disable the GC, you'll basically need to write your own runtime and standard library which works without leaking memory. Good luck! – Vladimir Panteleev Jun 18 '11 at 12:45
  • 1
    @CyberShadow: I didn't learn its garbage collector yet and hoped it won't be a problem. Bad news. Hope, it is possible to mitigate it. – Stas Jun 18 '11 at 12:52
  • There are a couple of ideas how to deal with GC for realtime systems. Looks good. http://www.digitalmars.com/d/2.0/memory.html – Stas Jun 18 '11 at 18:16
  • You can avoid the GC by simply not using it. Allocate and free memory manually like you do in C and C++ and the GC won't get in your way. – Peter Alexander Jun 18 '11 at 19:14
  • The biggest way to avoid the garbage collector is to favor structs over classes. The GC can also be temporarily deactivated so that it doesn't collect anything in sections of code which are performance critical. And, of course, `malloc` and `free` can be used directly. However, I wouldn't advise doing that with arrays. If you manually allocate arrays, you can't append to them or pass them to any functions which might cause the to reallocate, or you're going to have memory leaks. Slices also become problematic. So, you pretty much need the GC for arrays, but classes can avoid it if need be. – Jonathan M Davis Jun 19 '11 at 23:09

3 Answers3

13

I wouldn't consider D2 to be production ready yet, but it's getting close. The language definition is fairly stable. Very few breaking changes should be happening at this point (though some additive changes intended to iron out key issues in the language may occur). Development on the compiler is moving forward very quickly, and a lot of bugs are getting fixed. But at this point, if you use D2 heavily, you will run into compiler bugs, particularly if you use newer language features. And not all of those features have been fully implemented yet (e.g. alias this and inout), so while TDPL is mostly correct, dmd is still somewhat behind it.

Also, while the standard library, Phobos, is very good overall and much of it is stable, it's still very much a work in progress. We're trying to avoid causing immediate breaking changes by putting stuff that we're removing through the proper deprecation path (generally 6 months as scheduled for deprecation and 6 months as deprecated before complete removal), but sometimes immediate breaking changes do occur (and sometimes the compiler causes breaking changes as it's worked on). In some cases, entire modules are going to be overhauled (e.g. std.xml and std.stream). Possibly the biggest annoyance in that regard is std.container, which is fairly new, doesn't have a whole lot in it yet, and could have a significant redesign as Andrei Alexandrescu sorts out how we're going to deal with memory management in it. So, container support is improving but generally lacking. All in all, a lot of Phobos is fairly stable, but it's definitely not set in stone.

There is definitely support for both dmd and Phobos in that if you post things to bugzilla or discuss them on the newsgroup, people will generally be quite helpful and devs will try and fix bugs in a timely manner, but most of the people working on it do so in their free time, so sometimes it can take a while. The switch to github has definitely improved matters though. I know that Digital Mars provides additional support for dmc if you pay for it, but I don't know if they'll do the same for dmd. I expect that there's a good chance that they will though (certainly, if they don't now, I would expect them to do so in the future).

As for the quality of the compiler, dmd uses Digital Mars' dmc as its backend, and dmc is the newest incarnation of the first C++ compiler to compile code natively (as opposed to translating it to C first), and Walter Bright, the creator of D, has been working on it ever since he created it. He's one of the best compiler writers out there and has created a number of optimizations which have become standard in C++ compilers (such as Return Value Optimization), but dmc doesn't have a lot of people working on it, and there are some areas in which it has fallen behind (such as floating point optimizations), and D is new enough that there's a lot of work to be done in optimizing it. As the bugs are fixed, I'm sure that more focus will eventually shift towards optimizing the language, and it will eventually be on par with C++ in most circumstances (and better in some), but right now it really depends on your code. Sometimes D is on par; sometimes it isn't.

Some people do use D2 in production code (in particular, I know that Adam D. Ruppe uses it for web development with the companies that he works with - he's a frequent poster on the D newsgroup), but I don't think that there are very many of them, and they generally avoid the newer, fancier features of the language (which is generally where the worst bugs are). How stable it's going to be is really going to depend on what you do with the language.

The wiki has some good information on the work remaining to be done, and this recent thread on the newsgroup has some good info as well.

D is definitely approaching the point where I would consider it production ready, but there's definitely some risk at this point. It's great for hobby stuff, but if your livelihood depends on it, I don't know if the risk is worth it quite yet. It's getting close though. It's probably worth your time to look into it, try it out, experiment with it, etc. But I wouldn't just dive in with your production code and convert it all to D. It might work out great, but it might not. I expect that a year from now, I'll be able to say that D2 is production ready, but I don't know how much sooner than that I'll feel comfortable in saying so.

Jonathan M Davis
  • 37,181
  • 17
  • 72
  • 102
11

Is there any example of such migration or existing big commercial software product written on D from the scratch?

I don't believe there have been any large commercial migrations to D, although there are a few companies using D1. I don't know of any companies using D2 yet.

How is it safe to invest in this language now?

Do we have production quality compiler and debugger?

The DMD compiler is very strong and is continually improving, but is still lacking in some key areas. For example, its code generation for floating point operations is pretty lacking, and 64-bit support is flaky (although improving). There is also GDC, which I haven't used, but I get the impression that it is weaker than DMD.

Can we assume that they will be supported and developed?

I think it's very safe to assume that the compilers will be supported and developed. Just look at the github page for D. Activity is strong and growing. The number of bug fixes is coming in at a rapid pace and I see no signs of it slowing down.

Peter Alexander
  • 53,344
  • 14
  • 119
  • 168
  • `The DMD compiler's ... 64-bit support is flaky (although improving)` Does it have *any* 64-bit support? – user541686 Jun 20 '11 at 17:28
  • I believe 64-bit "works" on Linux, although has problems. – Peter Alexander Jun 20 '11 at 18:11
  • Oh whoops, my bad. I was thinking of Windows. – user541686 Jun 20 '11 at 18:22
  • Windows will be supported at some point (Digital Mars started out as a Dos/Windows tool after all) but I don't know if anyone is willing to say when, so it may even be a few *years* down the line. (Or someone might step up, take it on and Windows will be on par with Linux in the next month or two, you never know.) – BCS Jun 22 '11 at 01:55
5

Well, the general recommendation for any language is to not rewrite an existing code base. Writing new code or converting portions, where bugs need fixed, can be a good strategy.

The quick and dirty replay: If you have to ask, you shouldn't be using D in production yet.

Some don't consider D to be an improvement and others think it will remain in the "spheres of irrelevancy." Looking at its history shows that it has what it takes to survive.

Personally if I were to pitching the idea of having production product using D I'd probably consider:

  • Team size. How many developers need to be educated on D in the early stages to its completion.
  • What libraries will be needed and would we have the time and man power to build or wrap a library.
  • Would we be able to handle patching bugs in libraries used.
  • Would an architecture be need that isn't supported by DMD

These are concerns which will be part of any discussion especially for a young language like D, which has even broken compatibility with existing libraries making it only about 4 years old (and still survived). I don't use other compilers so not having support from DMD would be concerning, the history of the other compilers isn't stellar and it is good to have the knowledge there could be another compiler to fall back on. Of course if you have a crew that could maintain a compiler...

I think D can be used in production, but is something that should probably be very controlled. You'd want someone familiar with D on a team that is going to be making a production product with it, for now.

he_the_great
  • 6,554
  • 2
  • 30
  • 28