18 ms·

D Language accepted for inclusion in GCC

528 points by deng 9y ago

LukeShu 9y ago
There has been out-of-tree GCC support for D for several years. I wonder what has changed that they're letting it in to the official repository.
- theandrewbailey 9y ago
  The reference compiler got open sourced about 2 months ago. https://news.ycombinator.com/item?id=14060846 https://news.ycombinator.com/item?id=14060846
  - CogitoCogito 9y ago
    How does this work exactly from a licensing perspective? Will they merge the dmd sources into the gcc tree? Does this mean that the D compiler in gcc will now be GPL(v?) licensed? This is certainly possible since dmd is licensed permissively. https://github.com/dlang/dmd/blob/master/LICENSE.txt https://github.com/dlang/dmd/blob/master/LICENSE.txt I don't mean this to start a fight over licenses I'm just curious how it works when gcc lets other projects in.
    - ben-schaaf 9y ago
      I don't see how dmd would be mergable with gcc, completely different backends. gdc however is a different story.
      - jpf91 9y ago
        Although the recent DMD backend license change does not affect GDC, GDC is not a complete standalone implementation of a D compiler. GDC (and LDC, the LLVM D compiler) use the frontend (lexer, parser,semantic) provided by the DMD reference compiler. GDC and LDC then map the AST produced by the frontend to something GCC and LLVM understand. The DMD frontend has always been boost licensed. So the licensing question is valid here as we'll include boost frontend code into GCC. But I don't really have an answer to the question ;-)
    - jabl 9y ago
      In general, it's possible to create a combined work made from parts with different licenses, provided that the licenses are compatible. So if you have part A licensed under, say, the MIT license, and part B licensed under the GPL, then the combined work falls under the GPL (due to the GPL "virability", and since the GPL and MIT are compatible in the sense that the GPL restrictions are a superset of MIT ). You can still later on extract part A and distribute that under the MIT license. I don't know the details of the D compiler frontend that has now become part of GCC, but I'd imagine its something like that. E.g. the GCC Go frontend is, AFAIK, BSD licensed.
  - qznc 9y ago
    The reference compiler is unrelated. The frontend has been Free Software since the beginning. The reference backend was only Open Source (not freely redistributable). So, alternative backends were plugged to the frontend, LLVM and GCC. They all share the same frontend still, although LLVM and GCC slightly lag behind the reference in version (LLVM is nearly in sync). This announcement is official recognition after Iain and helpers did the grunt work consistently for years now.
    - amyjess 9y ago
      > The reference backend was only Open Source (not freely redistributable). Free redistributibility is part of the Open Source Definition. It is literally the first item: https://opensource.org/osd-annotated https://opensource.org/osd-annotated
      - boondaburrah 9y ago
        I think they meant lower case "open source" (as in the source is open (anyone can read/compile it)). There are plenty of software that are open source but not freely distributable, such as Unreal Engine.
        davexunit 9y ago
        "open source", no matter the capitalization, means what the OSI has defined. Unreal Engine is neither Open Source nor open source. It is simply proprietary. To say otherwise is a practice known as "open washing" that companies use to appear community friendly when in fact they are not.
        mindcrime 9y ago
        This. While OSI may not have been successful in getting an official trademark on the phrase "Open Source", in practice almost everybody treats "Open Source" or "open source" as meaning what the Open Source Definition states. Other "source available" approaches are more correctly termed "shared source" or something.
- dbcurtis 9y ago
  My guess is that is also why. gcc wants to be assured there are sufficient maintainers. If a crew has been maintaining out-tree-support with a good track record, that demonstrates maintainability.
  - le-mark 9y ago
    Is this what happened to gcj, lack of maintainers? I always thought it was a shame support for it lapsed, a to native java compiler would be awefully nice to have.
    - dbcurtis 9y ago
      Could be. I don't know the specifics. I do know that the bar is pretty high, in general, before gcc will commit. I think that simply goes with the territory with such a large project where a lot of people depend on it to just work. For example, an acquaintance plays (at least used to) a large role in the AVR (8 bit) back-end. He went to a gcc summit to lobby for avr-gcc being upgraded to a support tier where functional (not performance) regressions would be release show-stoppers. His argument: Over a million downloads per month. It took that much to get the gcc steering committee to even consider it. gcc is a big project, they can't afford to make commitments lightly.
- phkahler 9y ago
  >> I wonder what has changed that they're letting it in to the official repository. <sarcasm (or something)> Because they need an alternative to the mess that is C++ and Rust is already married to LLVM.</sarcasm>
- ptrott2017 9y ago
  The out of tree codebase - was extensively updated with development being led by Ian Buclaw. Ian has given some presentations on all the changes and updates at the recent D language conference - Dconf 2017. see https://www.youtube.com/watch?v=g-5T4zlc_bc https://www.youtube.com/watch?v=g-5T4zlc_bc
- zombinedev 9y ago
  I think the main factor is that the primary contributor to GDC (Iain) made a giant push for this to happen in the last 6-12 months. Just look at this graph: https://github.com/D-Programming-GDC/GDC/graphs/contributors https://github.com/D-Programming-GDC/GDC/graphs/contributors Great work, Iain!!!
pjmlp 9y ago
Congratulations, it will be nice to have D as well as part of a GCC default install.
jjnoakes 9y ago
Does this mean D-via-GCC will be supported on more platforms going forward than what is supported today?
- qznc 9y ago
  Someone still needs to provide the man power for porting and maintaining those platforms.
  - jjnoakes 9y ago
    Yes, understood. What I don't know is how much D-specific work is needed in the gcc backend per-target-triple. If it's a small amount of work, and the only thing really preventing it is wider adoption, this news may be the kick that it needs. If it's a large amount of work, then this news likely won't change much.
    - jpf91 9y ago
      Likely none. Well, I guess that's kind of an oversimplification though so here's the detailed story: We require some per-target integration to provide correct version(ARM), version(linux) statements in D code and we need to know the size of a mutex on the target system. Iain is currently rewriting this code here: https://github.com/D-Programming-GDC/GDC/pull/500 https://github.com/D-Programming-GDC/GDC/pull/500 However, we already provide and the new, rewritten code will continue to provide this integration for many targets. For example, all debian targets should be working: https://packages.debian.org/experimental/gdc https://packages.debian.org/experimental/gdc The main problem with architecture support is porting the runtime library and phobos. Here ARM is supported, MIPS and PPC has seen some work from LDC devs but making this work fully on GDC might require some small changes, MinGW is broken (and was never fully supported). One caveat thought is that all D compilers mainly target 32 or 64 bit systems. So things won't just work without changes for 8bit targets, although we've seen proof of concept D code on 8bit and 16bit CPUs as well.
      - jjnoakes 9y ago
jacquesm 9y ago
That's really great news and ensures long term viability of the D language and associated eco system.
- nialv7 9y ago
  Remember gcc once had a Java compiler...
  - jacquesm 9y ago
    18 years is an ok commitment, especially given that there are other implementations available on those same platforms. This is likely not the case with 'D' for all the platforms that gcc targets.
kronos29296 9y ago
I have read many posts saying D was better than C++ as a language but there were no libraries for use case X. Now this may help popularise the language.
- iamNumber4 9y ago
  One of D's goals is to be ABI compatible with C and C++, ABI compatibility with C is 100% as I understand it. C++ is a work in progress. What is ABI compatiblity? in a nutshell it let's you use libraries from another programming language. In D, all you need is a D file that describes the C/C++ library as a wrapper so the D compiler knows what you are using. This means D will build upon everything that already exists for C/C++. You can intermix C/C++ and D in the same project if you so choose to. Which is really a big deal because you don't necessarily have to stop and rewrite years of code you might already have to start using D. Syntax wise D is a kin to C#/Java, so if you know C# or Java, jumping over to using D is just a matter of learning the language specific Gotchas and core libraries. So the learning curve is quite low if you know C/C++,C#, or Java. to see what D libraries are out there I suggest looking at http://code.dlang.org/ http://code.dlang.org/
  - copx 9y ago
    How would that even work? Modern C++ libraries are largely templates, templates which must be instantiated at compile-time i.e. you need a full C++ compiler to use C++ libraries directly. Said compiler must somehow work together with the D compiler here, which should lead to god-awful memory use, compilation time, and error messages.
    - _yosefk 9y ago
      Most useful C++ code is either not templates or it's templates which can be instantiated a finite number of times and then used like non-templated code. Most "header-only"/header-heavy C++ libraries which present the problem you mention solve problems like C++'s smart for loop working like "for x in xs" does in Python but not working like "for x,y in zip(xs,ys)" does or like "for i,x for enumerate(xs)" does etc.; you don't really need these outside C++ (whether you need them inside C++ is another question but it's irrelevant here.)
roryrjb 9y ago
Wow I literally just installed GDC today (as opposed to DMD which I've tried in the past) in order to support ARM as well as x86. Congrats on the inclusion!
deleted 9y ago
[deleted]
hellbanner 9y ago
I learned about D through Torus Trooper - a highspeed vector graphics game written in D http://www.asahi-net.or.jp/~cs8k-cyu/windows/tt_e.html http://www.asahi-net.or.jp/~cs8k-cyu/windows/tt_e.html
- Keyframe 9y ago
  That's ye olde D1 though. D2 is a different beast.
  - hellbanner 9y ago
    Changes: http://forum.dlang.org/thread/iolttq$qnn$1@digitalmars.com http://forum.dlang.org/thread/iolttq$qnn$1@digitalmars.com https://dlang.org/D1toD2.html https://dlang.org/D1toD2.html
castratikron 9y ago
I remember trying out D a few years ago. One of the things that threw me off was the bare-bones compiler. I think I was using the reference compiler at the time. The language itself I thought was pretty cool, slices are neat. I could really see D take off now that it's getting gcc support.
- Doxin 9y ago
  These days you'll probably want to be using dub, no matter which compiler you're using. Makes managing dependencies a lot easier, and compiling a simple `dub build` for projects of any complexity..
krylon 9y ago
Silly me, I was under the impression that gdc was already part of gcc... Well, so at least now I am no longer mistaken. ;-) I have tried to learn D repeatedly over the last couple of years, but I was usually scared off by how complex this language is. Even so, the syntax is far cleaner than C++[1]. Also, the last time I gave it a try, something finally clicked. I am not all there yet, but I am beginning to like it. The community is very friendly and helpful. Being able to ask stupid questions without being shouted at makes learning a language a lot easier. [1] To be fair, C++ has carried the baggage of backwards compatibility around since its birth, while D did not and could learn from what C++ got right and wrong.
- WalterBright 9y ago
  I was pleased to see that C++ finally gave up on trigraphs.
  - krylon 9y ago
    From a language-user point of view, Trigraphs are an arcane but irrelevant feature, insofar as ignoring them or even being unaware of them won't cause any harm. [I only happen to know what a trigraph is because I read a lot and have a brain that randomly holds on to pieces of information with an iron grip.] Never having written a compiler, I can only imagine how tedious supporting those must have been; and I would be willing to bet that trigraphs weren't even used much, because, among other reasons, hardly anyone knew of them, so it must have been really frustrating for people to support them. An Exercise in futility.
- bedros 9y ago
  I had the same feeling at first, then I built a hobby project using Python, and it was too slow, so, I rewrote it in D I really liked D after that, I felt I'm working with python but much faster. one advice, never use printf function in D, use write() and writeln()
joelthelion 9y ago
What does it bring over modern C++? Why would you want to use it?
- ComputerGuru 9y ago
  I don't view it's counterpart to be C++ these days; dlang is a GC'd language, so it's actually probably fairer to compare it to Go instead.
  - pjmlp 9y ago
    Oberon, Modula-3 and System C# among many others would beg to differ.
  - mhh__ 9y ago
    It is a clear alternative to C++. The GC is optional.
    - mehrdadn 9y ago
      Is it? Last time I checked a few years ago there were huge caveats to allocation Objects on the stack (I forget what they were) so unless something's drastically changed this doesn't seem like an honest assessment.
      - destructionator 9y ago
        The pitfalls aren't really any different than C++... either use some kind of smart pointer, or use caution not to escape references to stack memory (very easy mistake to make in D) or slice up the object by value (very difficult to do in D) and you'll be fine. The built-in `scope` syntax is deprecated (though making a comeback recently as more stuff gets implemented around it), but you can also do a library type fairly easily, just slightly heavier in syntax (you need to prepare the memory and construct the object in two separate lines) or prep work (write a struct which does both).
      - mhh__ 9y ago
eco 9y ago
This is basically the work of one tireless man; Iain Buclaw. Many thanks to him for putting in so much time and energy into this. It took 6 years from first submission to get it in. Here are the slides from his 2017 DConf talk about the work that went into making this happen: http://dconf.org/2017/talks/buclaw.pdf http://dconf.org/2017/talks/buclaw.pdf
- baybal2 9y ago
  Slowly but steadily. Given the fact that D has not managed to die when it had so many chances to, I tell that D has better chance at mass adoption as "a better C++" than the current wave of Swift/Rust/Go that rely on "life support" from a corporate donor.
  - steveklabnik 9y ago
    > the current wave of Swift/Rust/Go that rely on "life support" from a corporate donor. Most Rust contributors are not Mozilla employees. Losing people to work on Rust full-time would be a setback, but we're not really reliant on it; we'd evolve more slowly.
  - kibwen 9y ago
    It's a bit of a stretch to cast corporate funding as a negative, especially when the direction of Swift/Rust/Go are all mostly directed by community consensus rather than the corporate middlemen signing the paychecks (see the Swift community's rejection of SE-0110, the Rust's community's rejection of struct inheritance, and the Go community's rejection of aliases). Given the opportunity I'm sure that D would delight in having a corporate sponsor; financial security of D development and infrastructure was a large part of the impetus for the D Language Foundation, after all. Casting sponsorship as "life support" when all three of these languages have thriving communities simply comes across as petty.
    - steveklabnik 9y ago
      D also has a foundation model, which could (I don't know anything about their financials) provide similar support to a company, but spread among companies instead.
fithisux 9y ago
While I like D and use it for scientific work, wwo "omissions" leave me a bitter taste. Nothrow and Pure are not part of the type signature of functions and consequently the compiler has limited inference about these. However I will keep using it unless something better comes up. C++/C# are not an option for me since I found D.
- nialv7 9y ago
  I thought they are?
  - WalterBright 9y ago
    They are.
    - fithisux 9y ago
      I stand corrected.
- EvenThisAcronym 9y ago
  >Nothrow and Pure are not part of the type signature of functions Actually they are. Take a look at this example: void main() { int delegate(int) @safe nothrow @nogc pure f; //This looks like something bad is happening, but the delegate literal //actually has the proper attributes inferred so it Just Works f = delegate(int) { return 0; }; int delegate(int) g; f = g; //Fails, as it should }
lasermike026 9y ago
Shouldn't gcc be working to catch up to llvm?
- mhh__ 9y ago
  Some benchmarks favour LLVM, some favour GCC.
Keyframe 9y ago
This is great and might interest me back to D, after many years of absence! When is inclusion expected, at which version / snapshot?
int_19h 9y ago
Is there a D IDE with good code completion and refactoring support? Last time I tried it, all that I've seen were pretty bad at it - handling the simple stuff fine, but breaking down on more complicated stuff, metaprogramming especially (kinda like most C++ IDEs did 8 years ago or so).
- pirocks 9y ago
  Due to the high complexity of d and the small community, there are currently no "great " ides.
- mhh__ 9y ago
  Code completion yes. (DCD provides this as a library). d-mode for emacs is nice, both of the plugins for vs-code I know work. There are plugins/extensions for (i think) xcode and (i know) Jetbrains's stuff (I don't use it so i can't really comment. Refactoring, no. Edit: There is also a D-specific IDE called coedit, which is pretty good AFAIK
  - VHRanger 9y ago
    Also a visual studio plugin
    - int_19h 9y ago
      I've tried VisualD, DlangIDE, and VSCode plugin. All seemed to be handling completion very poorly, and "Go to definition" basically not at all.
  - johnhattan 9y ago
    I just checked out Coedit. It looks quite nice, although I'm rather baffled that it's written in Pascal. I assume it's forked from an existing open-source editor, but there's nothing in the source headers to say which one.
    - pirocks 9y ago
      I think it's based on Lazarus.
srcmap 9y ago
Human societies seem to evolve to fewer languages. Fewer languages help everyone communicate easier/better. Programming languages seem to go the opposite direction. Any speculation on why?
- brokencode 9y ago
  Maybe because it takes most people hundreds or thousands of hours to learn a natural language, but the average programmer can get a basic understanding of a new programming language over a weekend? Plus, there's arguably no advantage of one natural language over another, whereas different programming languages can make very different tradeoffs.
- biotronic 9y ago
  Humans started out with only one very limited language, then spread out to cover the world, and new languages flourished. As technology progressed and the world became smaller, having fewer languages (or at least, a few common languages) made more sense. With the advent of the internet, the world has become so small a single language might be the best option. Programming started out with one very limited language (machine code), the spread out to cover the world, and new languages flourished. As technology progresses and the world becomes smaller, having fewer languages (or at least, a few common languages) will make more sense. With the advent of the singularity, the world will have become so small a single language might be the best option.=
systems 9y ago
it seemed like facebook was interested in d for a while, but then it also seems they dropped it in favour of ocaml i think so, because i believe ocaml and d do compete, and it is clear facebook stopped using d and now used ocaml in several project, they even created reason any idea why facebook dropped d
tejasmanohar 9y ago
What's the main draw towards D? Who's using it in production?
- merdreubu 9y ago
  https://dlang.org/orgs-using-d.html https://dlang.org/orgs-using-d.html
mahdix 9y ago
This is awesome! Congrats!
eggy 9y ago
I just started looking into D, and I was wondering about its future as part of my evaluation. Now, I feel it will benefit from being part of the GCC 'canon', and gain more of a user-base, and contributors.
jeffdavis 9y ago
I am learning rust now, but D seems quite promising. Rust guides you more toward certain approaches. That makes rust easier to learn, but it makes it harder to integrate with existing projects. On paper, rust could work great in a lot of environments, but I'm finding that it takes a bit more work to integrate with a real codebase. It can be done, and I feel like that's well supported, but it takes some real work to port the concepts of a C API into a good and safe rust API. D might make that easier because it's an "everything" language, so there is likely a corresponding D equivalent of almost any existing API. Of course, you won't get the same level of safety or other benefits, but it could be a smoother path.

528 points by deng 9y ago

There has been out-of-tree GCC support for D for several years. I wonder what has changed that they're letting it in to the official repository.

theandrewbailey 9y ago
The reference compiler got open sourced about 2 months ago. https://news.ycombinator.com/item?id=14060846 https://news.ycombinator.com/item?id=14060846
- CogitoCogito 9y ago
  How does this work exactly from a licensing perspective? Will they merge the dmd sources into the gcc tree? Does this mean that the D compiler in gcc will now be GPL(v?) licensed? This is certainly possible since dmd is licensed permissively. https://github.com/dlang/dmd/blob/master/LICENSE.txt https://github.com/dlang/dmd/blob/master/LICENSE.txt I don't mean this to start a fight over licenses I'm just curious how it works when gcc lets other projects in.
  - ben-schaaf 9y ago
    I don't see how dmd would be mergable with gcc, completely different backends. gdc however is a different story.
    - jpf91 9y ago
      Although the recent DMD backend license change does not affect GDC, GDC is not a complete standalone implementation of a D compiler. GDC (and LDC, the LLVM D compiler) use the frontend (lexer, parser,semantic) provided by the DMD reference compiler. GDC and LDC then map the AST produced by the frontend to something GCC and LLVM understand. The DMD frontend has always been boost licensed. So the licensing question is valid here as we'll include boost frontend code into GCC. But I don't really have an answer to the question ;-)
  - jabl 9y ago
    In general, it's possible to create a combined work made from parts with different licenses, provided that the licenses are compatible. So if you have part A licensed under, say, the MIT license, and part B licensed under the GPL, then the combined work falls under the GPL (due to the GPL "virability", and since the GPL and MIT are compatible in the sense that the GPL restrictions are a superset of MIT ). You can still later on extract part A and distribute that under the MIT license. I don't know the details of the D compiler frontend that has now become part of GCC, but I'd imagine its something like that. E.g. the GCC Go frontend is, AFAIK, BSD licensed.
- qznc 9y ago
  The reference compiler is unrelated. The frontend has been Free Software since the beginning. The reference backend was only Open Source (not freely redistributable). So, alternative backends were plugged to the frontend, LLVM and GCC. They all share the same frontend still, although LLVM and GCC slightly lag behind the reference in version (LLVM is nearly in sync). This announcement is official recognition after Iain and helpers did the grunt work consistently for years now.
  - amyjess 9y ago
    > The reference backend was only Open Source (not freely redistributable). Free redistributibility is part of the Open Source Definition. It is literally the first item: https://opensource.org/osd-annotated https://opensource.org/osd-annotated
    - boondaburrah 9y ago
      I think they meant lower case "open source" (as in the source is open (anyone can read/compile it)). There are plenty of software that are open source but not freely distributable, such as Unreal Engine.
      - davexunit 9y ago
        "open source", no matter the capitalization, means what the OSI has defined. Unreal Engine is neither Open Source nor open source. It is simply proprietary. To say otherwise is a practice known as "open washing" that companies use to appear community friendly when in fact they are not.
        mindcrime 9y ago
        This. While OSI may not have been successful in getting an official trademark on the phrase "Open Source", in practice almost everybody treats "Open Source" or "open source" as meaning what the Open Source Definition states. Other "source available" approaches are more correctly termed "shared source" or something.
dbcurtis 9y ago
My guess is that is also why. gcc wants to be assured there are sufficient maintainers. If a crew has been maintaining out-tree-support with a good track record, that demonstrates maintainability.
- le-mark 9y ago
  Is this what happened to gcj, lack of maintainers? I always thought it was a shame support for it lapsed, a to native java compiler would be awefully nice to have.
  - dbcurtis 9y ago
    Could be. I don't know the specifics. I do know that the bar is pretty high, in general, before gcc will commit. I think that simply goes with the territory with such a large project where a lot of people depend on it to just work. For example, an acquaintance plays (at least used to) a large role in the AVR (8 bit) back-end. He went to a gcc summit to lobby for avr-gcc being upgraded to a support tier where functional (not performance) regressions would be release show-stoppers. His argument: Over a million downloads per month. It took that much to get the gcc steering committee to even consider it. gcc is a big project, they can't afford to make commitments lightly.
phkahler 9y ago
>> I wonder what has changed that they're letting it in to the official repository. <sarcasm (or something)> Because they need an alternative to the mess that is C++ and Rust is already married to LLVM.</sarcasm>
ptrott2017 9y ago
The out of tree codebase - was extensively updated with development being led by Ian Buclaw. Ian has given some presentations on all the changes and updates at the recent D language conference - Dconf 2017. see https://www.youtube.com/watch?v=g-5T4zlc_bc https://www.youtube.com/watch?v=g-5T4zlc_bc
zombinedev 9y ago
I think the main factor is that the primary contributor to GDC (Iain) made a giant push for this to happen in the last 6-12 months. Just look at this graph: https://github.com/D-Programming-GDC/GDC/graphs/contributors https://github.com/D-Programming-GDC/GDC/graphs/contributors Great work, Iain!!!

pjmlp 9y ago

Congratulations, it will be nice to have D as well as part of a GCC default install.

jjnoakes 9y ago

Does this mean D-via-GCC will be supported on more platforms going forward than what is supported today?

qznc 9y ago
Someone still needs to provide the man power for porting and maintaining those platforms.
- jjnoakes 9y ago
  Yes, understood. What I don't know is how much D-specific work is needed in the gcc backend per-target-triple. If it's a small amount of work, and the only thing really preventing it is wider adoption, this news may be the kick that it needs. If it's a large amount of work, then this news likely won't change much.
  - jpf91 9y ago
    Likely none. Well, I guess that's kind of an oversimplification though so here's the detailed story: We require some per-target integration to provide correct version(ARM), version(linux) statements in D code and we need to know the size of a mutex on the target system. Iain is currently rewriting this code here: https://github.com/D-Programming-GDC/GDC/pull/500 https://github.com/D-Programming-GDC/GDC/pull/500 However, we already provide and the new, rewritten code will continue to provide this integration for many targets. For example, all debian targets should be working: https://packages.debian.org/experimental/gdc https://packages.debian.org/experimental/gdc The main problem with architecture support is porting the runtime library and phobos. Here ARM is supported, MIPS and PPC has seen some work from LDC devs but making this work fully on GDC might require some small changes, MinGW is broken (and was never fully supported). One caveat thought is that all D compilers mainly target 32 or 64 bit systems. So things won't just work without changes for 8bit targets, although we've seen proof of concept D code on 8bit and 16bit CPUs as well.
    - jjnoakes 9y ago

jacquesm 9y ago

That's really great news and ensures long term viability of the D language and associated eco system.

nialv7 9y ago
Remember gcc once had a Java compiler...
- jacquesm 9y ago
  18 years is an ok commitment, especially given that there are other implementations available on those same platforms. This is likely not the case with 'D' for all the platforms that gcc targets.

kronos29296 9y ago

I have read many posts saying D was better than C++ as a language but there were no libraries for use case X. Now this may help popularise the language.

iamNumber4 9y ago
One of D's goals is to be ABI compatible with C and C++, ABI compatibility with C is 100% as I understand it. C++ is a work in progress. What is ABI compatiblity? in a nutshell it let's you use libraries from another programming language. In D, all you need is a D file that describes the C/C++ library as a wrapper so the D compiler knows what you are using. This means D will build upon everything that already exists for C/C++. You can intermix C/C++ and D in the same project if you so choose to. Which is really a big deal because you don't necessarily have to stop and rewrite years of code you might already have to start using D. Syntax wise D is a kin to C#/Java, so if you know C# or Java, jumping over to using D is just a matter of learning the language specific Gotchas and core libraries. So the learning curve is quite low if you know C/C++,C#, or Java. to see what D libraries are out there I suggest looking at http://code.dlang.org/ http://code.dlang.org/
- copx 9y ago
  How would that even work? Modern C++ libraries are largely templates, templates which must be instantiated at compile-time i.e. you need a full C++ compiler to use C++ libraries directly. Said compiler must somehow work together with the D compiler here, which should lead to god-awful memory use, compilation time, and error messages.
  - _yosefk 9y ago
    Most useful C++ code is either not templates or it's templates which can be instantiated a finite number of times and then used like non-templated code. Most "header-only"/header-heavy C++ libraries which present the problem you mention solve problems like C++'s smart for loop working like "for x in xs" does in Python but not working like "for x,y in zip(xs,ys)" does or like "for i,x for enumerate(xs)" does etc.; you don't really need these outside C++ (whether you need them inside C++ is another question but it's irrelevant here.)

roryrjb 9y ago

Wow I literally just installed GDC today (as opposed to DMD which I've tried in the past) in order to support ARM as well as x86. Congrats on the inclusion!

deleted 9y ago

[deleted]

hellbanner 9y ago

I learned about D through Torus Trooper - a highspeed vector graphics game written in D http://www.asahi-net.or.jp/~cs8k-cyu/windows/tt_e.html http://www.asahi-net.or.jp/~cs8k-cyu/windows/tt_e.html

Keyframe 9y ago
That's ye olde D1 though. D2 is a different beast.
- hellbanner 9y ago
  Changes: http://forum.dlang.org/thread/iolttq$qnn$1@digitalmars.com http://forum.dlang.org/thread/iolttq$qnn$1@digitalmars.com https://dlang.org/D1toD2.html https://dlang.org/D1toD2.html

castratikron 9y ago

I remember trying out D a few years ago. One of the things that threw me off was the bare-bones compiler. I think I was using the reference compiler at the time. The language itself I thought was pretty cool, slices are neat. I could really see D take off now that it's getting gcc support.

Doxin 9y ago
These days you'll probably want to be using dub, no matter which compiler you're using. Makes managing dependencies a lot easier, and compiling a simple `dub build` for projects of any complexity..

krylon 9y ago

Silly me, I was under the impression that gdc was already part of gcc... Well, so at least now I am no longer mistaken. ;-) I have tried to learn D repeatedly over the last couple of years, but I was usually scared off by how complex this language is. Even so, the syntax is far cleaner than C++[1]. Also, the last time I gave it a try, something finally clicked. I am not all there yet, but I am beginning to like it. The community is very friendly and helpful. Being able to ask stupid questions without being shouted at makes learning a language a lot easier. [1] To be fair, C++ has carried the baggage of backwards compatibility around since its birth, while D did not and could learn from what C++ got right and wrong.

WalterBright 9y ago
I was pleased to see that C++ finally gave up on trigraphs.
- krylon 9y ago
  From a language-user point of view, Trigraphs are an arcane but irrelevant feature, insofar as ignoring them or even being unaware of them won't cause any harm. [I only happen to know what a trigraph is because I read a lot and have a brain that randomly holds on to pieces of information with an iron grip.] Never having written a compiler, I can only imagine how tedious supporting those must have been; and I would be willing to bet that trigraphs weren't even used much, because, among other reasons, hardly anyone knew of them, so it must have been really frustrating for people to support them. An Exercise in futility.
bedros 9y ago
I had the same feeling at first, then I built a hobby project using Python, and it was too slow, so, I rewrote it in D I really liked D after that, I felt I'm working with python but much faster. one advice, never use printf function in D, use write() and writeln()

joelthelion 9y ago

What does it bring over modern C++? Why would you want to use it?

ComputerGuru 9y ago
I don't view it's counterpart to be C++ these days; dlang is a GC'd language, so it's actually probably fairer to compare it to Go instead.
- pjmlp 9y ago
  Oberon, Modula-3 and System C# among many others would beg to differ.
- mhh__ 9y ago
  It is a clear alternative to C++. The GC is optional.
  - mehrdadn 9y ago
    Is it? Last time I checked a few years ago there were huge caveats to allocation Objects on the stack (I forget what they were) so unless something's drastically changed this doesn't seem like an honest assessment.
    - destructionator 9y ago
      The pitfalls aren't really any different than C++... either use some kind of smart pointer, or use caution not to escape references to stack memory (very easy mistake to make in D) or slice up the object by value (very difficult to do in D) and you'll be fine. The built-in `scope` syntax is deprecated (though making a comeback recently as more stuff gets implemented around it), but you can also do a library type fairly easily, just slightly heavier in syntax (you need to prepare the memory and construct the object in two separate lines) or prep work (write a struct which does both).
    - mhh__ 9y ago

eco 9y ago

This is basically the work of one tireless man; Iain Buclaw. Many thanks to him for putting in so much time and energy into this. It took 6 years from first submission to get it in. Here are the slides from his 2017 DConf talk about the work that went into making this happen: http://dconf.org/2017/talks/buclaw.pdf http://dconf.org/2017/talks/buclaw.pdf

baybal2 9y ago
Slowly but steadily. Given the fact that D has not managed to die when it had so many chances to, I tell that D has better chance at mass adoption as "a better C++" than the current wave of Swift/Rust/Go that rely on "life support" from a corporate donor.
- steveklabnik 9y ago
  > the current wave of Swift/Rust/Go that rely on "life support" from a corporate donor. Most Rust contributors are not Mozilla employees. Losing people to work on Rust full-time would be a setback, but we're not really reliant on it; we'd evolve more slowly.
- kibwen 9y ago
  It's a bit of a stretch to cast corporate funding as a negative, especially when the direction of Swift/Rust/Go are all mostly directed by community consensus rather than the corporate middlemen signing the paychecks (see the Swift community's rejection of SE-0110, the Rust's community's rejection of struct inheritance, and the Go community's rejection of aliases). Given the opportunity I'm sure that D would delight in having a corporate sponsor; financial security of D development and infrastructure was a large part of the impetus for the D Language Foundation, after all. Casting sponsorship as "life support" when all three of these languages have thriving communities simply comes across as petty.
  - steveklabnik 9y ago
    D also has a foundation model, which could (I don't know anything about their financials) provide similar support to a company, but spread among companies instead.

fithisux 9y ago

While I like D and use it for scientific work, wwo "omissions" leave me a bitter taste. Nothrow and Pure are not part of the type signature of functions and consequently the compiler has limited inference about these. However I will keep using it unless something better comes up. C++/C# are not an option for me since I found D.

nialv7 9y ago
I thought they are?
- WalterBright 9y ago
  They are.
  - fithisux 9y ago
    I stand corrected.
EvenThisAcronym 9y ago
>Nothrow and Pure are not part of the type signature of functions Actually they are. Take a look at this example: void main() { int delegate(int) @safe nothrow @nogc pure f; //This looks like something bad is happening, but the delegate literal //actually has the proper attributes inferred so it Just Works f = delegate(int) { return 0; }; int delegate(int) g; f = g; //Fails, as it should }

lasermike026 9y ago

Shouldn't gcc be working to catch up to llvm?

mhh__ 9y ago
Some benchmarks favour LLVM, some favour GCC.

Keyframe 9y ago

This is great and might interest me back to D, after many years of absence! When is inclusion expected, at which version / snapshot?

int_19h 9y ago

Is there a D IDE with good code completion and refactoring support? Last time I tried it, all that I've seen were pretty bad at it - handling the simple stuff fine, but breaking down on more complicated stuff, metaprogramming especially (kinda like most C++ IDEs did 8 years ago or so).

pirocks 9y ago
Due to the high complexity of d and the small community, there are currently no "great " ides.
mhh__ 9y ago
Code completion yes. (DCD provides this as a library). d-mode for emacs is nice, both of the plugins for vs-code I know work. There are plugins/extensions for (i think) xcode and (i know) Jetbrains's stuff (I don't use it so i can't really comment. Refactoring, no. Edit: There is also a D-specific IDE called coedit, which is pretty good AFAIK
- VHRanger 9y ago
  Also a visual studio plugin
  - int_19h 9y ago
    I've tried VisualD, DlangIDE, and VSCode plugin. All seemed to be handling completion very poorly, and "Go to definition" basically not at all.
- johnhattan 9y ago
  I just checked out Coedit. It looks quite nice, although I'm rather baffled that it's written in Pascal. I assume it's forked from an existing open-source editor, but there's nothing in the source headers to say which one.
  - pirocks 9y ago
    I think it's based on Lazarus.

srcmap 9y ago

Human societies seem to evolve to fewer languages. Fewer languages help everyone communicate easier/better. Programming languages seem to go the opposite direction. Any speculation on why?

brokencode 9y ago
Maybe because it takes most people hundreds or thousands of hours to learn a natural language, but the average programmer can get a basic understanding of a new programming language over a weekend? Plus, there's arguably no advantage of one natural language over another, whereas different programming languages can make very different tradeoffs.
biotronic 9y ago
Humans started out with only one very limited language, then spread out to cover the world, and new languages flourished. As technology progressed and the world became smaller, having fewer languages (or at least, a few common languages) made more sense. With the advent of the internet, the world has become so small a single language might be the best option. Programming started out with one very limited language (machine code), the spread out to cover the world, and new languages flourished. As technology progresses and the world becomes smaller, having fewer languages (or at least, a few common languages) will make more sense. With the advent of the singularity, the world will have become so small a single language might be the best option.=

systems 9y ago

it seemed like facebook was interested in d for a while, but then it also seems they dropped it in favour of ocaml i think so, because i believe ocaml and d do compete, and it is clear facebook stopped using d and now used ocaml in several project, they even created reason any idea why facebook dropped d

tejasmanohar 9y ago

What's the main draw towards D? Who's using it in production?

merdreubu 9y ago
https://dlang.org/orgs-using-d.html https://dlang.org/orgs-using-d.html

mahdix 9y ago

This is awesome! Congrats!

eggy 9y ago

I just started looking into D, and I was wondering about its future as part of my evaluation. Now, I feel it will benefit from being part of the GCC 'canon', and gain more of a user-base, and contributors.

jeffdavis 9y ago

I am learning rust now, but D seems quite promising. Rust guides you more toward certain approaches. That makes rust easier to learn, but it makes it harder to integrate with existing projects. On paper, rust could work great in a lot of environments, but I'm finding that it takes a bit more work to integrate with a real codebase. It can be done, and I feel like that's well supported, but it takes some real work to port the concepts of a C API into a good and safe rust API. D might make that easier because it's an "everything" language, so there is likely a corresponding D equivalent of almost any existing API. Of course, you won't get the same level of safety or other benefits, but it could be a smoother path.