I wonder if there are plans to add the support for D in the official releases of gcc .

My question is more about simplifying logistics, I already have different versions of different compilers in my system, and been able to avoid building yet another set of compilers ( different versions of gdc ) is kinda of a significant deal for me .

On Fri, 26 Sep 2014 13:53:58 +0000
"Ledd via D.gnu" <d.gnu@puremagic.com> wrote:

> I wonder if there are plans to add the support for D in the official releases of gcc .
it's good as the "sign of official acceptance", but GCC release cycle is too slow for D. i'm very unsure if making gdc part of gcc will do any good for D and gdc.

On Friday, 26 September 2014 at 22:21:13 UTC, ketmar via D.gnu wrote:
> On Fri, 26 Sep 2014 13:53:58 +0000
> "Ledd via D.gnu" <d.gnu@puremagic.com> wrote:
>
>> I wonder if there are plans to add the support for D in the official releases of gcc .
> it's good as the "sign of official acceptance", but GCC release cycle
> is too slow for D. i'm very unsure if making gdc part of gcc will do
> any good for D and gdc.

I don't think that the gcc team is slow on releasing new releases and patches, 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. My assumption is that D needs to freeze at some point .

Ledd:

> My assumption is that D needs to freeze at some point .

The problem we are having now is that D is too much frozen...

Bye,
bearophile

On Sat, 27 Sep 2014 11:47:33 +0000
"Ledd via D.gnu" <d.gnu@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. ;-)

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

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.

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

On 27 September 2014 13:11, ketmar via D.gnu <d.gnu@puremagic.com> wrote:
> On Sat, 27 Sep 2014 11:47:33 +0000
> "Ledd via D.gnu" <d.gnu@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. ;-)
>
>> 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.
>
> 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.
>

And for sure, the team pushing for DDMD will have to be a little more backwards compatible than previous release can build next release.

On Saturday, 27 September 2014 at 12:12:08 UTC, ketmar via D.gnu
wrote:
> On Sat, 27 Sep 2014 11:47:33 +0000
> "Ledd via D.gnu" <d.gnu@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. ;-)
>
>> 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.
>
> 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.
>
> i once dreamt about GDC as part of GCC, but i changed my mind.

3 companies is a good start, but let me outline the fact that not
all the companies have the amount of people that Facebook has,
many many dev teams are composed of 3-4 people and there are an
indefinite amount of freelancer, I don't think that Facebook is a
good unit of comparison given this facts .
Also Facebook finds the resources and the time to build its own
version of PHP, I think that it's safe to say that they can even
afford to experiment with this kind of technologies .

My point being that for the majority of people, the ones that
work on open source projects, large projects, productions for the
masses, a stable language and a predictable release cycle, is
more valuable then a cutting-edge feature-reach language .

On Saturday, 27 September 2014 at 12:20:01 UTC, Iain Buclaw via D.gnu wrote:
> On 27 September 2014 13:11, ketmar via D.gnu <d.gnu@puremagic.com> wrote:
>> On Sat, 27 Sep 2014 11:47:33 +0000
>> "Ledd via D.gnu" <d.gnu@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. ;-)
>>
>>> 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.
>>
>> 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.
>>
>
> And for sure, the team pushing for DDMD will have to be a little more
> backwards compatible than previous release can build next release.

I can't see the problem, do you think that a rolling-release language is good for its own popularity and diffusion ?

The only credible alternative is that you make D extremely easy to refactor via automated tools so you can change it as much as you want while keeping the codebase working .

On 28 Sep 2014 09:50, "Ledd via D.gnu" <d.gnu@puremagic.com> wrote:
>
> On Saturday, 27 September 2014 at 12:20:01 UTC, Iain Buclaw via D.gnu
wrote:
>>
>> On 27 September 2014 13:11, ketmar via D.gnu <d.gnu@puremagic.com> wrote:
>>>
>>> On Sat, 27 Sep 2014 11:47:33 +0000
>>> "Ledd via D.gnu" <d.gnu@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. ;-)
>>>
>>>> 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.
>>>
>>> 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.
>>>
>>
>> And for sure, the team pushing for DDMD will have to be a little more backwards compatible than previous release can build next release.
>
>
> I can't see the problem, do you think that a rolling-release language is
good for its own popularity and diffusion ?
>
> The only credible alternative is that you make D extremely easy to
refactor via automated tools so you can change it as much as you want while keeping the codebase working .

To give one example, you can build gcc-4.8 using gcc-4.6, in which time, there have been up to a dozen or so D language releases, and let's say every other release has introduced a backwards incompatibility feature that required applying to Phobos immediately.

Why is this bad?  One thing that will change when gdc is part of gcc is that suddenly, more or less every Linux distribution (or at least the big distros) will start shipping gdc through their software repositories, and will only update them according to their own release schedule.

So ensuring that ie: gdc-5.1 can build gdc-5.2 when we switch to a self-hosted compiler is a pretty big deal.  And what I can see happening is either we'll fall behind the latest spec more rapidly, or minor releases will get very selective backports.  Neither of which I like the idea of doing.

Iain.

On Sun, 28 Sep 2014 08:44:20 +0000
"Ledd via D.gnu" <d.gnu@puremagic.com> wrote:

> My point being that for the majority of people, the ones that work on open source projects, large projects, productions for the masses, a stable language and a predictable release cycle, is more valuable then a cutting-edge feature-reach language .
so they can take a stable language with predictable release cycle and so on. C, for example. D must change faster, not slower. i can't see why i should lose features which makes D valuable for me to please imaginary future adopters.