Some Notes on 'D for the Win'

[via Digitalmars-d]

On Monday, 25 August 2014 at 13:30:45 UTC, Chris wrote:
> D on the other hand is already perfectly usable for production 
> code, which, for me, is the most important thing.

That would depend on what you mean by "usable for production 
code".

For me "usable" means that I can fix compiler/library bugs by 
recompiling the project 12 months from now without any source 
code changes. It also means no regressions and a long testing 
window.

> 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).

Well, I think it is important that you cannot know which part of 
Phobos you can rely on.

The basic problem here is that the D "managers" think that the 
language will take off if it gains more features. So new features 
are eagerly pushed without polish and serious harnessing.

I think the opposite is true, I think it will take off when 
people see that the distributed tar-ball only includes code that 
is polished and harnessed. (leaving the less robust stuff to 
other repositories or as an experimental switch)

> discontinued). I wonder how safe it would be to use Go in 
> production (breaking changes, availability / implementation of 
> useful features etc.)

Pretty safe!

https://golang.org/doc/devel/release.html

>
>> 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.

For contractual reasons, but based on real world management 
needs. The Java and Python runtimes have a stable configuration 
window of 12 months (meaning no changes without 12 months 
notice). While Go and PhP can be dropped by Gogle over night IIRC.

So, Go is not useful for production on App Engine unless you do 
double implementation (like reimplementing parts in Go for 
performance reasons).