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