
The reference D compiler is now open source - jacques_chirac
https://forum.dlang.org/post/oc8acc$1ei9$1@digitalmars.com
======
iamNumber4
Good news indeed.

Switched to D 4 years ago, and have never looked back. I wager that you can
sit down a C++/Java/C# veteran, and say write some D code. Here's the manual,
have fun. They will with in a few hours be comfortable with the language, and
be fairly competent D programmer. Very little FUD surrounding the switching to
yet another language with D.

D's only issue is that it does not have general adoption, which I'm willing to
assert is only because it's not on the forefront of the cool kids language of
the week. Which is a good thing. New does not always Mean, improved. D has a
historical nod to languages of the past, and is trying to improve the on
strengths of C/C++ and smooth out the rough edges, and adopt more modern
programming concepts. Especially with trying to be ABI compatible, it's a
passing of the torch from the old guard to the new.

Regardless of your thoughts on D; My opinion is I'm sold on D, It's here to
stay. In 10 years D will still be in use, where as the fad languages will just
be foot notes in Computer Science history as nice experiments that brought in
new idea's but were just too out there in the fringes limiting themselves to
the "thing/fad" of that language.

~~~
coding123
I think a lot of languages that get popular have to have a thing. Like a thing
they do well, and hopefully change the world a little...

Python had math and has lots more maths now. R also has math and started to
kill Python, but now Python has Tensorflow and PyTorch. Scala has Spark. Java
has Tomcat, and everything that followed, which is probably 20% of the world's
mass by volume. Go has Docker Ruby has/had a railroad or something? JS has
well, f... I don't know where to start here.

Does D have a thing?

~~~
WalterBright
> Does D have a thing?

Probably its most useful feature is rather subtle. It's very easy to express
diverse ideas in code in D without having to resort to contortions. It's
something people realize after having worked with D for a while.

It is not the result of having feature X (you can always find feature X in
other languages or a way to make X work), it's the combination of various X's.

For example, some algorithms express naturally in a functional manner, some
imperative, some OOP, etc. It isn't necessary to buy into a manner for the
whole program, just use the manner that fits the particular part of the
program.

You might like to use FP here and there, but don't want to deal with monads.
You can use OOP for the AST, but don't want to box integers into an OOP class.
You like dynamic typing for one type, but it's a bad fit for another. You can
garbage collect for a quick prototype or a seldom used part of the code, and
carefully manage memory for the release or the hot spots. (The Warp
preprocessor I wrote did that.
[https://github.com/facebookarchive/warp](https://github.com/facebookarchive/warp))

There's a lot less time hammering square pegs into round holes.

I've seen more than enough presentations on "How To Do Technique X In Language
Y" and everyone says how clever that is but the contortions are just too awful
to contemplate.

The flip side is that D won't be satisfying to a purist adherent of any of
those paradigms.

~~~
jordigh
I really like how purity in D is so... _practical_. I like that a for loop is
totally allowed in pure code as long as it modifies no data outside the pure
block. One of the most annoying things in Haskell was to translate some
algorithm that looks very natural in a for loop into some other sort of
combination of map or reduce or something even more complicated.

(Yes, I know Haskell can also fake for loops more cleanly with monads, but
they still feel awkward and unnatural.)

~~~
buzzybee
My recollection from the last time I worked with D was that pure could be more
complicated and strict than expected when using standard libraries functions,
e.g. using trigonometry sets hardware global state, thus impure. I don't
remember if there was a good workaround to convey intent of purity despite
that.

~~~
p0nce
In D "pure" means "referentially transparent".

------
jordigh
Walter, thank you so much for finally doing this! I am so happy that Symantec
finally listened. It must have been really frustrating to have to wait so long
for this to happen. I have really been enjoying D and I love all the
innovation in it. I'm really looking forward to seeing the reference compiler
packaged for free operating systems.

Thanks again, this news makes me very happy!

~~~
WalterBright
You're welcome! It makes me happy, too. I've wanted to do this for a very long
time.

~~~
johndubchak
In addition to your great work, Walter, Symantec really needs extra
acknowledgement for the effort on their side in releasing their right to claim
in order to make this happen.

It seems we haven't had a lot of good things to say lately about Symantec and
I hope this gives them something positive to celebrate.

------
tombert
Honestly, since I'm slightly psychotic about these things, this is a kind of
huge to me. Part of the reason I never learned D was because the compiler was
partly proprietary.

Now I have no excuse to avoid learning the language, and that should be fun.

~~~
nialv7
There have been fully open source compiler for D for a long time: LDC and GDC.

~~~
AsyncAwait
Yup, but to be fair, they sometimes lack quite a bit behind dmd.

~~~
klickverbot
Just to clarify:

LDC master is on 2.073.2 right now (the latest DMD release), with a
2.072.2-based release imminent, and work towards 2.074.0 (currently in beta)
already underway.

GDC is sadly a different story, though.

------
WalterBright
And best of all, it's the Boost license!

Here it is:

[https://github.com/dlang/dmd/pull/6680](https://github.com/dlang/dmd/pull/6680)

~~~
omginternets
Why is this a good thing? I'm not familiar with the Boost license.

~~~
jacques_chirac
It is the least encumbering, very permissive and very well regarded in both
oss and corporate circles. Really a good choice to stick with it.

~~~
milesrout
That doesn't make it good. That makes it bad. It doesn't protect the rights of
users. It's really important that developer tools are GPL, as that prevents
vendor lock-in and EEE tactics.

~~~
ChickeNES
How is preventing me from making a closed sourced derivative of dmd in any way
protecting my rights as a a user of the source?

~~~
throwaway7645
A two-edged sword in my opinion. GPL always protects the end-user so they can
get the source, but it infringes on the creator trying to make closed source
software. So as a user I like GPL, but when programming I tend to mostly avoid
it. Mine mine mine! :)

------
vram22
Good to hear the news, and congrats to all involved.

Since I see some comments in this thread, asking what D can be used for, or
why people should use D, I'm putting below, an Ask HN thread that I had
started some months ago. It got some interesting replies:

Ask HN: What are you using D (language) for?

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

~~~
mochomocha
Too late to the party to add my answer to your AskHN, but here we go: I use D
at Netflix for machine learning backend.

~~~
WalterBright
Please consider adding to [http://dlang.org/orgs-
using-d.html](http://dlang.org/orgs-using-d.html)

------
JoshTriplett
Interesting change! Before, people had a choice between the proprietary
Digital Mars D (dmd) compiler, or the GCC-based GDC compiler. And apparently,
since the last time I looked, also the "LDC" compiler that used the already-
open dmd frontend but replaced the proprietary backend with LLVM.

I wonder how releasing the dmd backend as Open Source will change the balance
between the various compilers, and what people will favor going forward?

~~~
WalterBright
Each of dmd/gdc/ldc has their individual strengths and styles. It's an
embarrassment of riches.

~~~
JoshTriplett
> Each of dmd/gdc/ldc has their individual strengths and styles.

I'd be really interested to hear a comparison of those from someone
experienced with D and its community.

~~~
Ace17
Professional D coder here.

\- DMD is by far the D compiler with the shortest compile time. It's actually
so fast that it comes with a utility, 'rdmd', which compiles-then-execute a D
program. Say goodbye to shell/perl/python scripts, now you can have compile-
time checks without an explicit/slow compilation step. We use it for
automation tasks.

\- GDC is the compiler of choice when it comes to supporting multiple targets
and cross-compilation. It closely follows GCC and G++ command line
conventions, meaning that using a single properly written Makefile it's easy
to target x86/x86_64/arm, GNU/Linux (or Windows, but the mingw support has
been in statis for years). Debian comes with pre-compiled arm-targetting GDC
compiler. gdb, gcov, and operf work well. The generated code is fast (more
than LDC), we use it for heavy computation tasks.

~~~
mamcx
How good is D for:

-iOS? -Android? -Windows?

~~~
qznc
iOS: Experimental
[https://wiki.dlang.org/LDC#iOS_.28iPhone_OS.29](https://wiki.dlang.org/LDC#iOS_.28iPhone_OS.29)

Android: Experimental
[https://wiki.dlang.org/Build_LDC_for_Android](https://wiki.dlang.org/Build_LDC_for_Android)

Windows: Works. Here is the Visual Studio Integration
[https://github.com/dlang/visuald](https://github.com/dlang/visuald)

------
brakmic
Please don't get me wrong, as I don't want to start a flame here, but why do
they call D a "systems programming language" when it uses a GC? Or is it
optional? I'm just reading through the docs. They do have a command line
option to disable the GC but anyway...this GC thing is, imho, a no-go when it
comes to systems programming. It reminds me of Go that started as a "systems
programming language" too but later switched to a more realistic "networking
stack".

Regards,

~~~
asimpletune
Why does gc disqualify a language as a system's language?

P.S. I think of a system's language as one that runs directly on the machine,
e.g. Swift, C, go. They operate at the "system" level.

~~~
brakmic
Could one write a driver in D?

~~~
qznc
Here is someone writing a kernel in D:
[https://github.com/Vild/PowerNex](https://github.com/Vild/PowerNex)

~~~
Ace17
Another kernel written in D:
[https://github.com/xomboverlord/xomb/tree/unborn](https://github.com/xomboverlord/xomb/tree/unborn)

~~~
steveklabnik
Ah, the memories...

------
saosebastiao
This was something that always rubbed me the wrong way about the language, and
it was an impediment for adoption for me (for D, but also Shen and a few
others). In this era, there is no excuse for a closed source reference
compiler (I could care less if it's not a reference compiler, I just won't use
it). I'm surprised it took this long to do this, it seems like D has lost most
of its relevance by now...relevance it could have kept with a little more
adoption. I wonder if it can recover.

~~~
qznc
D is easier than Rust and safer than C++. That is a valuable point IMHO.

~~~
saosebastiao
I agree it is valuable.

But I still think there are better alternatives now. Depending on your
priorities and constraints, OCaml, Go, F#, Scala, and Swift all fit the same
description (easier than Rust, safer than C++) and they're in the same realm
for performance (slower than C, C++, Rust, etc., but not by much). D could
have been there if they had a decade or so with a bigger community.

~~~
qznc
D certainly has made a few mistakes and having a non-free backend in dmd was
one of them. I doubt this could have been avoided though. It was just
technical debt, which Symantec now graciously payed off. I have great respect
for the Rust people, because it seems they do everything right so far.

I am a sucker for language discussions, so let me explain what my problems are
with your suggestions.

Ocaml: No support for parallelism, community is even smaller than D, do they
have a package manager, yet?

Go: I like generics/templates. If I throw away type safety, I might as well
use Python.

F#: I use Linux. The .NET ecosystem is not strong here.

Scala: I don't like the JVM. Also, the Scala compiler is slow.

Swift: Solid ideas, but held back by Object-C compatibility. I don't build iOS
apps, so why bother.

~~~
zem
yes, ocaml has opam as a package manager now. the community has also grown
quite a bit recently.

------
bluecat
Something I always thought was cool about dlang was that you can talk to the
creator of the programming language on the forums. I don't write much D code
as of now, but I always visit the forums everyday for the focused technical
discussions. Anyways, congrats on the big news!

------
softinio
Whats special about D? why should i learn it?

~~~
amelius
Also, how does D compare to Rust?

(If I'm going to learn a new system programming language, which one should I
pick?)

~~~
Rusky
D has been around longer, has powerful compile-time metaprogramming tools, and
has a very fast compiler. However, it has a garbage collector, and is not
entirely memory-safe by default (though is beginning to optionally incorporate
some ideas from Rust [edit: or not], maybe making that easier once you put in
the work). It seems to follow C or C++ in what sorts of things it makes
language-level features.

Rust is newer (though being used in some big projects like Firefox/Servo,
Visual Studio Code's search functionality now uses it by default, etc), has
(afaiu) a more powerful type system, and is entirely memory-safe by default.
However, this makes it somewhat harder to learn at first, and it also has a
relatively slow compiler. It follows ML-style languages a bit more, with
things like pattern matching and sum types built into the language.

Personally, I prefer Rust, because it feels like a stronger foundation with
the ML-like type system and no GC. YMMV though, depending on what is important
to you.

~~~
WalterBright
D's memory safe notions are very different from Rust's.

~~~
dbaupp
Could you be more specific? It doesn't seem like there's much room in the
conventional definition of memory safety (e.g.
[https://en.wikipedia.org/wiki/Memory_safety](https://en.wikipedia.org/wiki/Memory_safety)
) for variation, other than, I suppose, putting conditions on when/which
things are actually guaranteed.

~~~
WalterBright
[https://wiki.dlang.org/DIP25](https://wiki.dlang.org/DIP25)

[https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md](https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md)

~~~
dbaupp
Hm, I'm not sure I understand how that's answering my question. Neither of
those seem to even define what the "memory safety" notion means for D so I
can't compare. And, looking into it further, none of the links from
[https://dlang.org/spec/memory-safe-d.html](https://dlang.org/spec/memory-
safe-d.html) define (or compare) what D means by "memory safety"/if it differs
to the conventional definition.

I guess your original comment was maybe meaning _how_ D enforces (the "normal"
definition of) memory safety differs to Rust? In any case, I read over both of
those, and, to me, they both seem to essentially be a slightly less general
version of Rust's scheme (possibly independently invented), rather than
something very different. I'm interested to hear how you think they
specifically differ to Rust.

~~~
WalterBright
Memory safety in D is the usual definition - making memory corruption
impossible.

There's no notion of "borrowing" in D nor any notion of "only one mutable
access at a time".

~~~
dbaupp
By not having borrowing, do you mean the compiler doesn't stop one from
mutating something that has a dependent scoped pointer pointing into it? How
does D avoid dangling pointers for that?

~~~
leshow
It has a GC, I think.

------
jacquesm
That is excellent news :)

Congratulations Walter, now let's see D take over the world.

~~~
WalterBright
[https://www.youtube.com/watch?v=DslPaayoB30&feature=youtu.be...](https://www.youtube.com/watch?v=DslPaayoB30&feature=youtu.be&t=102)

~~~
jacquesm
Hehe. You've got my vote. Oh wait.

------
zerr
Anybody worked on performance critical stuff in D? How good is its GC?

~~~
bachmeier
I think it's common to avoid the GC in performance critical sections of your
code. D's version of BLAS is faster[1] and avoids the GC completely.

[1]
[http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/...](http://blog.mir.dlang.io/glas/benchmark/openblas/2016/09/23/glas-
gemm-benchmark.html)

~~~
openasocket
consistently beating OpenBLAS and having performance comparable with MKL is
seriously impressive. I'm wondering how that is possible. I assume it's using
the same algorithms as other implementations, so the credit goes to the
compiler (and to the language to some extent). But the D compiler just uses
LLVM for the back end, so is this because LDC produces really good LLVM IR, or
is LLVM really good at generating assembly? Either way I'm really impressed
they can beat hand-tuned assembly, I'd love to see a comparison between the
resulting assembly for Mir GLAS and OpenBLAS.

~~~
klickverbot
LDC dev here. All the credit for this goes to Ilya Yaroshenko for the expertly
crafted implementation and the LLVM developers for efficient low-level code
generation (inlining, register allocation and so on, and in some places auto-
vectorization). LDC only needs to make sure not to "mess up" things too much.

D does play a significant role in this achievement, though – D's very powerful
yet easy to use features for generics and introspection make it possible to
finely tune the code for different parameters (sizes/dimensions/…) while still
being easy to understand and modify.

~~~
openasocket
That's helpful, thanks!

I definitely appreciate the power of generics, especially when you can to
generics over values instead of just types. But I'm having trouble seeing the
value of the compile-time introspection, for the most part it doesn't seem to
give you much more power than generics do. Could you give me an example of the
"killer feature" introspection gives over generics? Bonus points if you can
compare it to Rust-style generics with traits and specialization.

~~~
nicwilson
Many things, although introspection works glove in hand with generics. Below
os a non-exhaustive list.

You can 'Write once - automate everywhere' all the boilerplate. See
[https://github.com/kaleidicassociates/excel-d/](https://github.com/kaleidicassociates/excel-d/)
, for an example of automating the interaction between D and Excel. I am in
the process of doing something similar for OpenCL and CUDA and will be
presenting it at Dconf.

You can make at compile time (additional) fast paths by checking to see if a
type (or symbol or whatever else) provides a fast primitive to accelerate your
algorithm. e.g. if Foo implements fastfoo use that otherwise fallback to a
general algorithm.

See also Andrei Alexandrescu's 2016(15?) talk (IIRC the relevant section is
about half way through
[https://www.youtube.com/watch?v=4oDK91E3VKs](https://www.youtube.com/watch?v=4oDK91E3VKs)).

------
Samathy
Amazing! D has really been exciting me for the past couple of years. It has
great potential.

Hopefully a fully FOSS compiler will bring it right into the mainstream.

------
petre
Is there support for BigFloat in D/phobos or any auxiliary library? I was
playing around with D sequences and wrote a D program that calculates a
Fibonacci sequence (iterative) with overflow detection that upgrades reals to
BigInts. I wanted to also use Binet's formula which requires sqrt(5) but it
only works up to n=96 or so due to floating point precision loss.

------
xtreak_1
Thanks a lot! I am also consistently amazed at the performance of the forum
like any other day even though the story is on top of HN.

------
petre
This is great news. I was using LDC because the DMD backend was proprietary.
Thank you Walter, Andrei and whoever made this possible.

~~~
klickverbot
We LDC developers of course hope that you will continue to use LDC for all
your non-x86 and high-performance needs. ;)

~~~
petre
It produces smaller binaries and it has fast compilation times. So yes, I will
continue using it on x86 as well.

------
fithisux
No matter what people say about the applicability of Dlang, Dlang has a very
bright future in science. GIS, compilers, math environments will benefit by
translating to D instead of C++. D is my language of choice for this stuff.

------
noway421
It's really surprising that to this day, there are languages in use which have
its reference implementation closed source. All the possible optimizations and
collaboration possible when it's open is invaluable.

------
virmundi
Has there been any new books out there to learn D? I have one that still
references the Collection Wars (Phobos vs Native). Once I saw that, I put the
book back on the shelf and stuck with Java.

~~~
WalterBright
[https://wiki.dlang.org/Books](https://wiki.dlang.org/Books)

------
snackai
This is big. Heard from mmany people that this avoids adoption.

------
tbrock
Is anyone else surprised that it wasn't before?

------
herickson123
I wanted to play around with D using the DMD compiler but it's unfortunate I
have to install VS2013 and the Windows SDK to work with 64-bit support in
Windows. I've installed VS in the past and found it to be a bloated piece of
software I'm not willing to do again.

------
imode
what is it like to 'bootstrap' D? I know in many languages you can forego the
standard library and 'bootstrap' yourself on small platforms (C being the main
example).

------
sgt
Off topic question; are you related to
[https://en.wikipedia.org/wiki/Jacques_Chirac](https://en.wikipedia.org/wiki/Jacques_Chirac)
?

------
spicyponey
Tremendous effort. Congrats.

------
nassyweazy
This is an awesome news!

------
joshsyn
Please get rid of GC :(

I want to have smart pointers instead

~~~
qznc
No problem, just add the @nogc annotation to your main function.

    
    
        int main(string[] args) @nogc { ... }

~~~
Rusky
I haven't used D much- how much of an impact does that have when using the
standard library or other libraries? Is there a good way to use things that
assume a GC even when it's disabled?

~~~
bionsuba
There are many parts of the std lib that assume GC usage. When you mark a
function as @nogc, DMD does a compile-time check and will not compile your
program if there's a GC call. Applying this to main means that your entire
program will by necessity be GC free.

~~~
Rusky
Right, I understand that it effectively eliminates GC usage, I'm just
wondering how much of an impact that has on what tools you have. In the
extreme, I can imagine it degenerating into basically writing C, for example.

~~~
bionsuba
You have access to all of std.range and std.algorithm, most of std.datetime,
many functions in std.string and std.digest, and others scattered throughout
the std lib. The main thing you'll want to look at is
std.experimental.allocator, which has tons of tools for manual memory
allocation.

Most of the community packages out there use the GC. Some though are
transitioning to a std.experimental.allocator interface, like this containers
library
[https://github.com/economicmodeling/containers](https://github.com/economicmodeling/containers)

