This is an oldish article (1995) that compares development costs of C and Ada: http://www.adaic.org/whyada/ada-vs-c/cada_art.html

D is generally a safer language than C, and more productive too. On the other hand Ada has some safeties that D lacks still (and I think D may enjoy having some of them), like for example regarding safety of type conversion, integral overflows, and other things (regarding performance, Ada is similar to statically compiled languages). D requires less lines of code than C and Ada (especially if you use higher order functors like std.algorithm of D2 or my ones), so I think overall the development costs of D may be intermediate between C and Ada ones :-)

Regarding the SafeD I want to say something: I like the idea of SafeD, but safety comes from many things, and not just a single source. So I think SafeD has to improve other things too. Restricting the "safe" of SafeD to just one things (that is just eliminating pointers, I think), goes against the concept of safety. If you want a safer D, then you have to look at doing other things too in a safer way. Because the end purpose of a programmer that wants to use SafeD may be to write safer code, and in real programs bugs doesn't come from a single source! (that is, pointers).

Just for example, Safe D may enforce a safer indenting of code, to avoid the "dangling else" bug (it seems I was quite right, and GCC designers have had the same idea of mine, take a look at recently added warnings of GCC, -Wparentheses and -Wsequence-point here, http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html  I think such things have to be built-in in SafeD), take better care of integral overflows, etc.

Bye,
bearophile

bearophile wrote:
> Just for example, Safe D may enforce a safer indenting of code, to
> avoid the "dangling else" bug (it seems I was quite right, and GCC
> designers have had the same idea of mine, take a look at recently
> added warnings of GCC, -Wparentheses and -Wsequence-point here,
> http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html  I think such
> things have to be built-in in SafeD), take better care of integral
> overflows, etc.

SafeD is about guaranteeing memory safety, not other issues like integer overflows. Memory safety is a fairly specifically defined thing.

Walter Bright:
> SafeD is about guaranteeing memory safety, not other issues like integer overflows. Memory safety is a fairly specifically defined thing.

Then maybe the name of SafeD isn't too much good, because when I hear that name I think about a safe(r) language, and not about memory safety only. So maybe an alternative name can be invented... (but I have no good name to suggest you so far).

Bye,
bearophile

bearophile wrote:

> Walter Bright:
>> SafeD is about guaranteeing memory safety, not other issues like integer overflows. Memory safety is a fairly specifically defined thing.
> 
> Then maybe the name of SafeD isn't too much good, because when I hear that name I think about a safe(r) language, and not about memory safety only. So maybe an alternative name can be invented... (but I have no good name to suggest you so far).
> 
> Bye,
> bearophile

I've always understood the 'safety' here as safe from buffer overflow exloits and such, instead of safety against bugs in general. (security).

Lutger wrote:
> bearophile wrote:
> 
>> Walter Bright:
>>> SafeD is about guaranteeing memory safety, not other issues like
>>> integer overflows. Memory safety is a fairly specifically defined
>>> thing.
>> Then maybe the name of SafeD isn't too much good, because when I
>> hear that name I think about a safe(r) language, and not about
>> memory safety only. So maybe an alternative name can be invented...
>> (but I have no good name to suggest you so far).
>> 
>> Bye, bearophile
> 
> I've always understood the 'safety' here as safe from buffer overflow
> exloits and such, instead of safety against bugs in general.
> (security).

Exactly. http://en.wikipedia.org/wiki/Memory_safety

Walter Bright:
> Lutger wrote:
> > I've always understood the 'safety' here as safe from buffer overflow exloits and such, instead of safety against bugs in general. (security).
> 
> Exactly. http://en.wikipedia.org/wiki/Memory_safety

OK, I'll wait for the coming of SecureD then :-)

Bye,
bearophile