Is D appropriate for creating a stable production app?

[Burton Radons]

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.