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