Some Notes on 'D for the Win'

[Chris via Digitalmars-d]

On Monday, 25 August 2014 at 12:35:51 UTC, Ola Fosheim Grøstad 
wrote:
> On Monday, 25 August 2014 at 11:20:51 UTC, Chris wrote:
>> I sometimes have the feeling that because the D community 
>> discusses every tiny feature or change elaborately (and 
>> rightly so), people coming from the outside have the 
>> impression that it's a half-baked (and thus unreliable) thing.
>
> How is it not half-baked when DMD is released with regressions?
>
> D lacks proper quality assurance and a clear distinction by 
> experimental releases/features and production quality.
>
> Features should have at least 6-12 months of testing before 
> being used in production, IMO.
>
>> Other languages often just "cover up" the discussions, or in 
>> the case of Go, decisions are presented post factum (with a 
>> lot of hype and "Hurra!" around them), which gives the 
>> impression of a clean and tight (and thus reliable) project.
>
> Go has reached feature stability and does not push experimental 
> features into the production compiler. The libraries are 
> limited in scope and thus of reasonable quality AFAIK.
>
> Note that on Google App Engine the Go runtime is still listed 
> as experimental. Only Java 7 and Python 2.7 are labeled as 
> ready for production.
>
> The problem is that D  will stay at 95% done forever without 
> proper management.
>
> A common thumb-of-rule is that 90% remains to be done when 90% 
> of the code is written. I.e. the final polish, refactoring and 
> maintenance is the most work. Don't underestimate the 
> importance of the last 5%.
>
> Go is lack-lustre, but it is more mature than D.
>
>> So people from the outside have the impression that it's a bit 
>> of a mess and they are ignorant as regards features and 
>> improvements.
>
> The process is a mess if you don't do feature freeze on one 
> version that is mature and keep it in maintenance mode (only 
> receiving safety bug fixes and focusing on stability).

I'd say half-baked refers to real world usability. Nimrod would 
be half-baked, because it is still young and a lot of features 
will change (breaking changes). The language sounds interesting, 
but I wouldn't touch it right now. D on the other hand is already 
perfectly usable for production code, which, for me, is the most 
important thing. Whether or not the whole infrastructure is good 
enough (there's always room for improvement) is not so important 
for this particular aspect (i.e. actual coding). I started to use 
D before dub was the official package manager. Although I use dub 
a lot now, I could manage without it for two or more years (which 
in turn says a lot about D itself).

Here's a list of Go apps:

http://go-lang.cat-v.org/go-code

Similar to D apps. Some of them still going, some of them in a 
limbo, some of them dead (would be nice to know why they were 
discontinued). I wonder how safe it would be to use Go in 
production (breaking changes, availability / implementation of 
useful features etc.)

> Note that on Google App Engine the Go runtime is still listed 
> as experimental. Only Java 7 and Python 2.7 are labeled as 
> ready for production.

They are listed as "experimental" partly for legal reasons, I 
suppose, and "ready for production" still means "experimental". 
All software is experimental. No matter how you label it. Java 
has moved very slowly over the years and I think Go has kind of 
slowed down a bit. D is still moving quite fast as regards adding 
features and improvements and is remarkably stable and reliable.