www.digitalmars.com         C & C++   DMDScript  

D.gnu - D as first class language in the gcc milestones ?

reply "Ledd" <a3826447 trbvm.com> writes:
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 .
Sep 26 2014
parent reply "ketmar via D.gnu" <d.gnu puremagic.com> writes:
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=20
 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.
Sep 26 2014
parent reply "Ledd" <a3826447 trbvm.com> writes:
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 .
Sep 27 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Sep 27 2014
prev sibling next sibling parent reply "ketmar via D.gnu" <d.gnu puremagic.com> writes:
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=20
 and patches
they are much slower than D team.
 I think that on one hand it's true that D is=20
 currently a rapidly-changing language, but this also prevents a=20
 gain in popularity, no one wants to adopt a non-standard language=20
 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.
Sep 27 2014
next sibling parent reply "Ledd" <a3826447 trbvm.com> writes:
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 .
Sep 28 2014
parent reply "ketmar via D.gnu" <d.gnu puremagic.com> writes:
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.
Sep 28 2014
parent reply "Ledd" <a3826447 trbvm.com> writes:
On Sunday, 28 September 2014 at 11:19:21 UTC, ketmar via D.gnu 
wrote:
 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.
That's because you are not thinking about the "shipping date" as a feature, you are not even considering it as an option. You will never get 1 single customer if you say "I can do X for you but I can't determine when I'll ship that" . And any developer interested in D is a customer of yours . A predictable release cycle it's absolutely not about "losing features" C and C++ in the gcc compiler have all the bells and whistles, they even have the compiler support for technologies way beyond the ISO C or C++ standards . Also, on average, you get a new release of gcc every 2-3 months, with a new milestone being published in about 11-12 months . I can't think about this as a problem, there are commercial C/C++ compilers that don't have half of the same features that gcc offers . the first release of D1 is about 13 years old, D2 is about 7 years old, it's probably time to decide whether it will be a rolling-release language as long as it will live or to stabilize/standardize it . I don't think that keeping things as they are will do any good to D .
Sep 28 2014
parent "ketmar via D.gnu" <d.gnu puremagic.com> writes:
On Sun, 28 Sep 2014 16:39:29 +0000
"Ledd via D.gnu" <d.gnu puremagic.com> wrote:

 That's because you are not thinking about the "shipping date" as=20
 a feature, you are not even considering it as an option.
yes, 'cause FOSS projects has no "shipping dates".
 You will never get 1 single customer if you say "I can do X for=20
 you but I can't determine when I'll ship that" . And any=20
 developer interested in D is a customer of yours .
i'm not trying to sell them D. they either like it or not, but for me the primary goal of D is to satisfy *my* needs. i'm tired of tools that tries to satisfy someone else.
 A predictable release cycle it's absolutely not about "losing=20
 features"
i'm talking about long pauses between releases, not about "when it's done". and about desyncing between GCC and DMD release cycles.
 Also, on average, you get a new release of gcc every 2-3 months,
but not a packages in major distros. besides, main GCC languages (C and C++) aren't developing at the fast rate of D. and GCC's Go is old, and GCC's ObjC is old. can't see any good in adding another "always old" language to GCC.
 the first release of D1 is about 13 years old, D2 is about 7=20
 years old, it's probably time to decide whether it will be a=20
 rolling-release language as long as it will live or to=20
 stabilize/standardize it . I don't think that keeping things as=20
 they are will do any good to D .
and i think that D must change alot faster. we still can't remove some annoyances due to "this will break some code". dfix tool was rejected, and users telling that they are ready for code breaking are not heard. damn it, if i want language with such disgusting legacy i can use C++!
Sep 28 2014
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
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 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.
Sep 28 2014
parent "ketmar via D.gnu" <d.gnu puremagic.com> writes:
On Sun, 28 Sep 2014 14:50:25 +0200
"Leandro Lucarella via D.gnu" <d.gnu puremagic.com> wrote:

 I'm sorry, but at least the Sociomantic example is not a good one to
 defend your point.
ok, two companies. ;-) it still beats "noone".
 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.
but gcc package maintainers are not so fast. i still see gcc 4.9.0 on some distros, with it's known bug that makes ffmpeg flac decoder unusable, for example. ah, even gcc 4.8, 'cause "it's proven to be stable and we know it's bugs".
 And then you have Python, which has an history of providing a super
 stable language that evolves continuously.
especially Python3. and i seen real life examples of software that works with python2.5, but not with python2.7.
 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.
no, i'm not wrong. i'm talking about GDC, not about DMD. yes, svn version of GDC can get all the freshy fixes and enhancements, but people will use the version that comes with their distro. the old one. when GDC is not tied to GCC, maintaner can build GDC with new GCC backend, for example, and this will not force to upgrade to new GCC (my GDC is completely independed of my GCC, for example). and GDC maintainer can release packages when new GDC is ready, not when the whole new GCC is ready.
 i once dreamt about GDC as part of GCC, but i changed my mind.
You should keep dreaming :)
nonononono. ;-) GDC is my primary D compiler, yet i don't want it to be the part of GCC. what i really want is GDC which is synced with current DMD, but this is another story. ;-)
Sep 28 2014
prev sibling parent reply "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
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.
Sep 27 2014
parent reply "Ledd" <a3826447 trbvm.com> writes:
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 .
Sep 28 2014
parent "Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:
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.
Sep 28 2014