www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is D appropriate for creating a stable production app?

reply mmcdermo <morganmcdermott gmail.com> writes:
Repost from "The old D" newsgroup
Hello,
I am curious as to what all of you, being involved with the development of
some of the most fundamental parts of D's progression, have to say about
whether D should be used in a certain situation.

My business is developing a web application primarily coded in PHP, and for
performance reasons, many of the algorithms are to be made with a different
language. Our team greatly favors PHP over other languages, as we all have
grown accustomed to a method of creating applications with PHP that are
extremely easy to maintain over time, take little time to code, and are not
error-prone. However, we are also concerned very much so with performance, for
the end user's sake and for our own (Higher application performance means less
resources used, which ends up meaning more cash in our pocketbook), so we have
a need to use a different language for certain aspects of our base-framework.

We are looking into a vast array of different languages at this point,
analyzing the benefits and downsides of each. As none of us have very much
experience with the D language (beyond reading some documentation and
tutorials), I thought that a post here might help us learn more about the D
language and how it pertains to our situation.

While analyzing different languages, we look for these qualities:
1) Stability and reliance
2) Performance
3) Ease of code maintenance
4) Ease of implementation

Languages that top our list right now are C and C++, but due to D's similarity
to these languages and its improvements over both, I think it has a fair
chance of coming out on top. But then, I'm not very familiar with the D
language in the first place. Thus, I ask all of you D-Wizards for your input
and recommendations here, and thank you for taking the time to read this post
and maybe even taking the time to reply!
Nov 09 2006
next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"mmcdermo" <morganmcdermott gmail.com> wrote in message 
news:ej13rk$2gfu$1 digitaldaemon.com...

 1) Stability and reliance
As far as anything that hasn't been added in the past few months, D is pretty solid. Some new things are still a bit buggy (like variadic templates), but if you stick to the more tried-and-true features, you should be just fine. There are some bugs relating to imports and protection attributes, but nothing that can't be worked around. Additionally, Walter stated (just today!) that D 1.0 will be done by January 1, 2007, if you're looking to see if the D spec or compiler will ever stabilize.
 2) Performance
I've been very happy with D's performance. I've written a (relatively small) 3D game engine in D, and haven't had any trouble with it in terms of computational power. D is garbage-collected, which is something to keep in mind if you're going to be writing real-time applications, but with what I like to call "responsible memory management," GC collection cycles shouldn't noticeably interrupt your program very often, or at all. What I call "responsible" is basically you don't go around creating tons of objects for common tasks, use "auto" to have classes auto-destroyed at the end of scope where possible, try to deallocate/delete when you know it can be done, etc. But you don't have to be absolutely nitpicky about it like you do in C/C++. I like to use the GC as a failsafe for all the stuff that slips through the cracks.
 3) Ease of code maintenance
Fantastic. I look at C++ code and wonder how I'm supposed to comprehend any of it to any reasonable degree. It's always so laden with memory- and resource-management code, tons of (ugly, hard-to-parse) templates, and pointers. I look at D code and can understand what's going on almost immediately. With the much simpler syntax and lack of use of complex language features to do the simplest of tasks, D is certainly easier to read and maintain for me. I've written not only the game engine, but also a scripting language in D, and not once have I wanted for any kind of container classes or template library. Most of the default data structures in D are enough for most things I do.
 4) Ease of implementation
If you mean of the language itself, DMD comes with the source for the frontend, and there is a compiler, GDC, which takes that front end and attaches it to the Gnu compiler backend. They're the only two compilers that I know of, but since you've already got the frontend source, that should make implementation of a new compiler relatively simple (as long as you have experience implementing compilers!).
Nov 09 2006
prev sibling next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
I think you'll find the language itself is a joy to work with compared 
to C++.  Where it suffers is

1) IDE/Debugger support - not many options there yet.  writefln is 
pretty much your best bet.

2) Documentation - there's a spec, which is what I refer to most, but it 
often leaves details out, and is not really organized in such a way that 
things are easy to find.  Good thing is the newsgroup is pretty 
responsive and helpful anytime there's something you can't find in the docs.

3) Libraries.  There's a surprising amount of D code out there, but 
still it pales in comparison to an established decades-old language like C.

If you can live with the above 3, then D should be able to get the job 
done, and will be much more fun than using C++. :-)

One thing I'm curious about -- has anyone out there used D extensively 
for a 24/7 server type app?  I mean the kind of thing that would expose 
slow leaks in the GC and other robustness problems like that.

--bb

mmcdermo wrote:
 Repost from "The old D" newsgroup
 Hello,
 I am curious as to what all of you, being involved with the development of
 some of the most fundamental parts of D's progression, have to say about
 whether D should be used in a certain situation.
Nov 09 2006
next sibling parent Walter Bright <newshound digitalmars.com> writes:
Bill Baxter wrote:
 One thing I'm curious about -- has anyone out there used D extensively 
 for a 24/7 server type app?  I mean the kind of thing that would expose 
 slow leaks in the GC and other robustness problems like that.
The GC has been pretty heavily tested. It's 6 years old, and it's stood up extremely well.
Nov 09 2006
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Bill Baxter wrote:
 One thing I'm curious about -- has anyone out there used D extensively 
 for a 24/7 server type app?  I mean the kind of thing that would expose 
 slow leaks in the GC and other robustness problems like that.
I have the Bovis server project which is meant to run this way, and so far in the progressive test builds there haven't been any issues, but these have had fairly short uptimes (a couple of days or so at most). Hopefully soon I'll be pouring some time into it and have a more serious test build sitting and running around the same time D1.0 comes out. Then we will know. :) -- Chris Nicholson-Sauls
Nov 10 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
mmcdermo wrote:
<snip>
 
 While analyzing different languages, we look for these qualities:
 1) Stability and reliance
 2) Performance
 3) Ease of code maintenance
 4) Ease of implementation
 
 Languages that top our list right now are C and C++, but due to D's similarity
 to these languages and its improvements over both, I think it has a fair
 chance of coming out on top. But then, I'm not very familiar with the D
 language in the first place. Thus, I ask all of you D-Wizards for your input
 and recommendations here, and thank you for taking the time to read this post
 and maybe even taking the time to reply!
For numbers 3 and 4, I can confidently say that D beats C/C++ in those areas, no contest. Writing and maintaining code is much much simpler in D than it is in C++. Even for small trivial application. Can you imagine a program that doesn't use some form arrays? In C++, dealing with arrays and/or containers isn't very pleasant at all. What about strings? Again, a very basic construct that is needed in almost any application, even trivial ones. Well, these things are built-in to D, so there's no hassle here. Where as in C++, you're always gonna be in troubles when dealing with arrays and strings, and btw, you'll probably be using pointers a lot when doing that; where as with D, I haven't yet found a good reason to use pointers. The GC makes it all that much easier to maintain code, you never have to worry about tracking objects/pointers/whatever. You won't really appreciate the GC until you write code with no GC present. It just makes thing a lot easier, I don't know how to say that in better words.
Nov 09 2006
prev sibling parent reply Burton Radons <burton-radons smocky.com> writes:
mmcdermo wrote:
 Repost from "The old D" newsgroup
 Hello,
 I am curious as to what all of you, being involved with the development of
 some of the most fundamental parts of D's progression, have to say about
 whether D should be used in a certain situation.
 
 My business is developing a web application primarily coded in PHP, and for
 performance reasons, many of the algorithms are to be made with a different
 language. Our team greatly favors PHP over other languages, as we all have
 grown accustomed to a method of creating applications with PHP that are
 extremely easy to maintain over time, take little time to code, and are not
 error-prone. However, we are also concerned very much so with performance, for
 the end user's sake and for our own (Higher application performance means less
 resources used, which ends up meaning more cash in our pocketbook), so we have
 a need to use a different language for certain aspects of our base-framework.
Yuck, that brings back some bad memories. For the period of about a year I was exclusively programming in Python, and inevitably in a project there was this creep where I'd have to move more and more Python code into completely unintelligible C (SWIG was very basic at the time). My tour-de-force was this massive class written in C that could be overloaded by classes in Python that would call methods overridden in Python written a few days after that feature (overloading classes, not calling overridden methods - that was my own special insanity) entered beta and if I left it alone for a week and came back to it, I would have no idea what it was doing. In fact, it was so difficult to understand that I would know what the line of code I was working on was doing, but the function it was contained within was a mystery. It came to be that the majority of my time was maintaining and developing this layer, where I'd convert a few lines of Python into a few hundred lines of far faster C code, then spend ages trying to document it so that I could understand what the hell was going on afterwards. You might think I'm being hyperbolic, but I swear that is exactly how it happened, and it was completely necessary: the nightmare class I described above doubled my frame rate. Since then I've become convinced that there is no application where a scripting language makes sense, particularly when your compiler (dmd) is is as fast as or faster than a script compiler without requiring a hard-to-maintain layer telling one side how to work with the other. Everything you want to do with scripting can be done with D aside from making it safe, and I have my reasons for not giving a damn about making code safe.
 We are looking into a vast array of different languages at this point,
 analyzing the benefits and downsides of each. As none of us have very much
 experience with the D language (beyond reading some documentation and
 tutorials), I thought that a post here might help us learn more about the D
 language and how it pertains to our situation.
 
 While analyzing different languages, we look for these qualities:
 1) Stability and reliance
 2) Performance
 3) Ease of code maintenance
 4) Ease of implementation
 
 Languages that top our list right now are C and C++, but due to D's similarity
 to these languages and its improvements over both, I think it has a fair
 chance of coming out on top. But then, I'm not very familiar with the D
 language in the first place. Thus, I ask all of you D-Wizards for your input
 and recommendations here, and thank you for taking the time to read this post
 and maybe even taking the time to reply!
In my experience D is as productive to code in as Python (actually more so due to the many maintenance problems Python has), and the fragile import problems it used to have due to bugs in the compiler (it didn't like recursive imports) haven't shown themselves to me in over a year. This might be because I've gotten good at avoiding the bugs, but I think they're gone now. One problem I can foresee is that you'll need to spend a lot of effort writing a tool to have the D code define the interface to the PHP code, as it's unlikely such a tool (like SWIG) already exists. Also, D's inherent garbage collectiveness can make such interfaces very problematic. So instead I would recommend writing in D in the first place. It's slightly more difficult to output HTML, but when done properly (not with globals) is more robust. Aside from that, the need for main, and a less powerful standard library, moving to D from PHP should feel very natural. But there's no substitute to trying it yourself.
Nov 10 2006
parent reply mmcdermo <morganmcdermott gmail.com> writes:
Burton,
 Thank you very much for your detailed and useful reply. Your past situation
with
Python and C seems very similar to ours, and it sounds like we'd be wise to do a
good load of experimenting and reconsider the _primary_ language we're coding
in.
Your notes on D's productivity are especially tantalizing... If we can achieve
results anywhere near that of coding in Python, then one of the primary chains
holding PHP securely in its position of primary-programming-language might just
snap in two.

  Facing the remaining issues that challenge the pragmatism of using D primarily
will require more research and testing on our part, but I would be much obliged
if
you would help me understand one of the issues you touched on:
  You wrote, "Everything you want to do with scripting can be done with D aside
from making it safe..."
  Would you please explain what issues you are referring to here? Are these the
standard problems that face other similar languages (buffer overflows etc), or
are
you talking about D-specific vulnerabilities?

Thank you again for your assistance, Burton, and many times over for the
enlightening viewpoint you shared with me.
Nov 10 2006
parent Burton Radons <burton-radons smocky.com> writes:
mmcdermo wrote:
 Burton,
  Thank you very much for your detailed and useful reply. Your past situation
with
 Python and C seems very similar to ours, and it sounds like we'd be wise to do
a
 good load of experimenting and reconsider the _primary_ language we're coding
in.
 Your notes on D's productivity are especially tantalizing... If we can achieve
 results anywhere near that of coding in Python, then one of the primary chains
 holding PHP securely in its position of primary-programming-language might just
 snap in two.
I should add the caveat that this productivity is predicated on equivalent library support. PHP/Python has much richer and easier-to-use libraries (if you want to call autoconf easy to use - which it is, so long as /nothing goes wrong/), so it's far too easy to have to spend too much time making a library for D, depending upon what you're doing. However, libraries are generally once-written oft-used so I wouldn't consider that too big a deal and in my case, the problem I articulated is show-stopping; I won't use an interpreted language for anything.
   Facing the remaining issues that challenge the pragmatism of using D
primarily
 will require more research and testing on our part, but I would be much
obliged if
 you would help me understand one of the issues you touched on:
   You wrote, "Everything you want to do with scripting can be done with D aside
 from making it safe..."
   Would you please explain what issues you are referring to here? Are these the
 standard problems that face other similar languages (buffer overflows etc), or
are
 you talking about D-specific vulnerabilities?
D is in principle an unsafe language, but in practice is very safe - about as safe as any other. That is to say, you have free access to unsafe practices (pointers, explicit casts between pointer types), but you don't need to use them for the vast majority of code, and when you do, those features can be safely encapsulated in unbreakable libraries like std.boxer which have unit tests designed to ensure that all possible safe input to them has a safe result. Normally D does bounds checking for such activities as array access, so buffer overruns are not an issue. This can be turned off, but I discommend doing this because it's not that great a speed advantage (and can easily be worked around for inner loops), and this is usually turned off for release code - right when accurate debugging is most needed! It's like putting the best armour on your tank when you're test driving it on the base, then taking it all off when it's time to go out into the battlefield. So in summary, D makes safe code easier and more intuitive to write than unsafe code (contrast with C where writing unsafe code is far easier and often necessary), without removing the power and flexibility granted by having direct memory access, while at the same time giving the tools to make these dangerous operations as safe as possible. There are other issues involved with scripting, but it doesn't sound like running unauthenticated code is what you're using PHP for. If you want me to discuss the issues there I can.
 Thank you again for your assistance, Burton, and many times over for the
 enlightening viewpoint you shared with me.
Sure thing.
Nov 10 2006