D as first class language in the gcc milestones ?

[Leandro Lucarella via D.gnu]

ketmar via D.gnu, el 27 de September a las 15:11 me escribiste:
> On Sat, 27 Sep 2014 11:47:33 +0000
> "Ledd via D.gnu" <d.gnu at puremagic.com> wrote:
> 
> > I don't think that the gcc team is slow on releasing new releases 
> > and patches
> they are much slower than D team.
> 
> > I think that on one hand it's true that D is 
> > currently a rapidly-changing language, but this also prevents a 
> > gain in popularity, no one wants to adopt a non-standard language 
> > that is constantly mutating for production code.
> at least three companies already adopted D: Facebook, Sociomantic
> and... sorry, i forgot the third. so your "no one" is a slight
> exaggeration. ;-)

I'm sorry, but at least the Sociomantic example is not a good one to
defend your point. We are stuck at D1 because D2 was too unstable. So,
yeah, if you want the industry to adopt the language, at least from my
personal experience in Sociomantic, you need to provide stability and
predictability. The new release procedure has been a huge improvement on
this front, and the care it's being taken now in terms of not
introducing breaking changes (with low ROI at least, as Don put it in
DConf2013), and is why we can start thinking about a migration to D2.

GCC releases more or less every year a new minor version. I think
introducing new feature *just* once a year is super acceptable. Then,
they do a patchlevel release more or less once every 5 months. That
might be a bit slow for DMD, but is not that bad either, specially when
the compiler is getting more robust.

> > My assumption is that D needs to freeze at some point .
> ahem... we already have C++. ;-) it's not frozen, but it's legacy turned
> it to abomination.

And then you have Python, which has an history of providing a super
stable language that evolves continuously. You keep pointing to the
wrong examples ;-)

> i believe that shipping old D in distributives will harm D more than
> not shipping at all. people will write new code using obsolete
> features, fight with already-fixed bugs, and so on. being independent of
> GCC allow to avoid such problems, 'cause maintainer can build new
> package when new GDC is out. but if GDC will be the part of GCC, no
> updates will ship until new GCC is out, 'cause GDC release cycle will be
> dependent of GCC release cycle.

You got it all wrong. DMD is a compiler implementation and I didn't see
anyone here suggesting to tie DMD releases to GCC releases in any way.
What they are asking for is having GDC merged in GCC, that's all.

> i once dreamt about GDC as part of GCC, but i changed my mind.

You should keep dreaming :)

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
El día que falten los niños, que sobren las mujeres y que se prenda
fuego el último árbol, será el Apocalípsis.
	-- Ricardo Vaporeso. Camino Negro, 1916.