
D Language accepted for inclusion in GCC - deng
https://gcc.gnu.org/ml/gcc/2017-06/msg00111.html
======
eco
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
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.

~~~
geezerjay
If I'm not mistaken, Rust is being sold as a better C, not C++. Go is being
marketed as a higher level language than C and Rust focused on developing
network-aware concurrent applications to fill specific server needs. I may be
wrong, but I'm not really sure that they target C++ or aim to replace it,
unlike D.

Perhaps that's the reason why both Rust and Go managed to gain so much
traction and goodwill, because they actually offer entirely different takes on
programming. D, on the other hand, tried to fix problems that existed only due
to the lack of work developing C++ beyond the 98 standard. Once the C++11
standardization process took off, D was pushed away into irrelevance.

~~~
kibwen
_> I'm not really sure that they target C++ or aim to replace it, unlike D._

The evolution of both Go's and Rust's strategies as "replacement" languages is
actually pretty interesting.

While Go's official marketing no longer calls it a systems language, the use
of that phrase when Go was originally released does indicate that that they
envisioned Go to be a "better C" in a sense (perhaps specifically in the sense
of being used for userspace "system" utilities in the same vein as the Rob
Pike's C-like Alef on Plan 9). At the same time, much of the public rationale
given for Go was obviously to avoid the pitfalls of using C++ at Google-like
scales (e.g. an aversion to junior-dev footguns and a fanatical focus on fast
compilation), which implies that they saw some potential for replacing C++,
though they later acknowledged that very little of Go's growth appeared to be
coming from C++ programmers (see
[https://commandcenter.blogspot.com/2012/06/less-is-
exponenti...](https://commandcenter.blogspot.com/2012/06/less-is-
exponentially-more.html) : _" Although we expected C++ programmers to see Go
as an alternative, instead most Go programmers come from languages like Python
and Ruby. Very few come from C++."_).

Meanwhile, given that Mozilla intended to write a browser engine in Rust, old
versions of Rust absolutely intended to replace C++. Like D and Go, ancient
pre-0.1 Rust was willing to impose a runtime by default in order to guarantee
memory safety (originally intending for both green threads and a garbage
collector to be baked into the language), until years of experimentation
proved that its static checks were capable of providing memory safety without
a runtime, which is the pivotal moment in Rust history (actually a series of
pivotal moments, but let me be romantic). Nowadays, rather than market itself
as a C++ replacement exclusively, Rust tends to position itself outside of the
traditional spectrum of languages as simply a zero-overhead memory-safe
systems language. While it's still true Rust competes with C++, is inspired by
C++, and can be used to replace C++ (e.g. its usage at Dropbox and in
Firefox), Rust also intends to compete directly with C, e.g. for system
utilities (e.g. ripgrep), reusable low-level libraries (e.g. librsvg), and
extending high-level languages (e.g. Helix).

~~~
_ak
> While Go's official marketing no longer calls it a systems language, the use
> of that phrase when Go was originally released does indicate that that they
> envisioned Go to be a "better C" in a sense

Rob Pike uses the phrase within the first 5 minutes or so of the very first
presentation video announcing Go, and explicitly mentions that they mean
"systems" in the sense of webservers and the like. Since then, Go being a
systems language has endlessly (and often maliciously) been misrepresented, so
under these circumstances, it's only understandable why this phrase was
dropped, even though it was absolutely appropriate since its first use gave
plenty of context.

~~~
Ded7xSEoPKYNsDd
I don't think web servers clarifies much, though. The most important web
servers (Apache, nginx, ISS, etc.) are all written in C or C++, and they try
to squeeze out every bit of performance they can. I guess we're talking about
applications communicating over HTTP, but that's not my first thought when I
hear someone talking about web servers without any more context.

(I'm aware of Caddy, but my understanding is that it's aiming for ease of use
over performance.)

~~~
mholt
We'll focus on tuning performance after 1.0. ;)

------
krylon
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
I was pleased to see that C++ finally gave up on trigraphs.

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

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

~~~
afghanPower
D seems like a more useful Rust, or is that completely wrong?

~~~
nenreme
They are very different languages. Rust was designed to be GC-free and memory
safe. D, on the other hand, has GC and is memory unsafe by default.

~~~
issaria
Call me wrong if I misunderstood, but isn't reference counting also kind of
GC?

~~~
floatboth
Rust doesn't use reference counting (until you want to use it)

~~~
jordigh
Isn't borrow-checking a sort of compile-time reference counting? Not what
people usually think of when they say "reference counting", but I wonder if
it's a good way to think of borrow-checking.

~~~
leshow
Not really, it doesn't count references in the same way. The borrow checker
maintains a set of rules that are more expansive than reference counting. For
instance the rule that you may only have one &mut at a time, and no other
references as long as &mut is alive. It also has something like linear types
with ownership rules, where owned values can be used only once.

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

------
LukeShu
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
The reference compiler got open sourced about 2 months ago.

[https://news.ycombinator.com/item?id=14060846](https://news.ycombinator.com/item?id=14060846)

~~~
qznc
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
> 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
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
"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
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.

------
hellbanner
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
That's ye olde D1 though. D2 is a different beast.

~~~
hellbanner
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)

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

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

~~~
qznc
Someone still needs to provide the man power for porting and maintaining those
platforms.

~~~
jjnoakes
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
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
Glad to hear there's work in progress. Last time I tried to configure gcc +
gdc on AIX on PowerPC, I found out it was explicitly disabled in the configure
script, and I didn't dig any deeper to find out why or the potential work
involved.

~~~
jpf91
I guess that was quite some time ago?

Back then we had a shell script hack that was called by the GCC configure
script and parsed the target triplet to set these versions.

Fortunately that's long gone and we now simply add some D specific code to the
platform configuration files in gcc/config/ . The shell script hack would have
never passed the GCC review ;-)

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

------
fithisux
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
I thought they are?

~~~
WalterBright
They are.

~~~
fithisux
I stand corrected.

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

~~~
mhh__
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

~~~
johnhattan
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
I think it's based on Lazarus.

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

~~~
nialv7
Remember gcc once had a Java compiler...

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

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

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

------
roryrjb
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!

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

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

~~~
mhh__
It is a clear alternative to C++. The GC is optional.

~~~
mehrdadn
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
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).

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

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

~~~
merdreubu
[https://dlang.org/orgs-using-d.html](https://dlang.org/orgs-using-d.html)

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

------
mahdix
This is awesome! Congrats!

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

~~~
mhh__
Some benchmarks favour LLVM, some favour GCC.

