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
I'm so, so happy that after close to a decade of tireless work D is finally in gcc. I don't have much to add except congratulations to Ian for his mostly solo work on this. Having D "standardised" in this fashion within the GNU project can do nothing but benefit both D and GNU.
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.
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.
It's much more anti-fragile to have corporations who sponsor projects (as do we) than one or two key official sponsors. And it suits D's breadth too, because there's no single company that uses D for everything that's possible to do with it. Makes sense for Google to sponsor Go. Who is supposed to sponsor a language with versatility that encompasses C,C++ and Python and runs on the gamut of platforms. A single sponsor using D on Linux might direct energy away from Windows and embedded...
Mozilla is not a normal corporation though. I donate, and I suspect many others do, as well. So maybe rust could be seen to have a lot of tiny sponsors rather than one big one?
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.
I don't think it's meaningful to put Swift, Rust and Go in a single bucket when comparing them. They're languages targeting different levels of abstraction, with very different approaches as a result.
Some people refer to all of these as "better C++", but it's meant in very different and incomparable ways. For example, Rust is ostensibly a "better C++" in a sense that it retains the low-level, zero-overhead (no GC) etc nature and powerful metaprogramming facilities. Go is a ostensibly a "better C++" because it promotes higher-level, safer abstractions that are still "fast enough" (but not zero-overhead). Ditto Swift.
D is arguably in the same bucket as Swift, and partly as Go. I don't think it's very useful to compare and contrast it against Rust. And I think that of all of these, Rust is the only one that can truly claim to be a "better C++" in a meaningful way. Others are "something better than C++ for most apps you'd write in C++ today".
> D is arguably in the same bucket as Swift, and partly as Go. I don't think it's very useful to compare and contrast it against Rust.
It is easy to claim how things "arguably" are, but without providing any justification that is not a very meaningful statement to make.
D very much matches your definition of "low-level, zero-overhead (no GC) etc nature and powerful metaprogramming facilities" – the GC can be avoided easily enough. It can certainly claim to be a "better C++" in this sense. For instance, Weka.IO (a storage startup founded on D) heavily relies on D to offer exactly that, in order to implement a distributed file system with sub-100µs latency.
The fact that you can also write Python-esque code during prototyping (playing fast and loose with the GC, etc.) doesn't detract from the core identity of the language as a tool for systems programming with zero-cost abstractions.
It seems like use-after-free is still a potential issue, even with those guard rails.
Rust deals with those through named lifetimes --would those ideas be useful in D as well?
I don't think a "better Python" can be statically typed - dynamic typing, and all the associated runtime tricks that you can do with it, is kinda part of what makes Python distinctive (whether for good or bad, opinions differ there).
This is consumer-side duck typing. Python also provides producer-side duck typing - you can make any of your objects a duck dynamically, by making them behave like a duck at runtime. I'm not aware of anything similar in Go wrt interfaces.
Rust also shines when it comes to high level abstractions. This is what attracts me to the language: as in C++, it covers the super low-level stuff, but it also powerful in business logic abstractions.
Go has far more in common with Java than it does with python. Arcane APIs that are incredibly difficult to use correctly while having a very simple base language.
I found the Go APIs I have worked with far more simple and idiomatic than any Java libraries I have worked with (which is admittedly not a lot).
It is, to a degree a matter of taste, of course, but Go APIs tend to be rather simple, whereas Java libraries seem to often have FileOpenDialogStyleTemplateProcessorFactoryFactory-type interfaces.
The major problem I have with Go currently is lack of function overloading, which means you either have to convert your data around a lot or have many similar functions for different data types that do the same thing (basically), but have different names.
I think the comparison with Python is quite fitting, because both languages encourage a certain way to think about and implementing things. For Python it's called pythonic, in Go it's called idiomatic.
No as Go has a GC. It's just supposed to be a fast server-side language without very complicated code. Go is mostly successful due to Google and filling a niche (fast, simple, concurrent, all thrown into a fat statically linked binary I think).
> Others are "something better than C++ for most apps you'd write in C++ today".
As big C++ fan and language geek, I am pretty confident that if Java and .NET had taken the route of all other alternatives in the 90's (Oberon, Eiffel, Modula-3, Delphi,...), C and C++ would be less relevant today than they turned out to be.
This because many people make use of them, just because they are the only languages they know about compilers that produce AOT executables, with the option of static linking them.
Maybe even Longhorn would have been a success, instead of having to wait for UWP with .NET Native.
Indeed. With C# especially it is rather ironic, because the timeline of its development closely overlaps with D - I remember learning the newly released C# 1.0 as I was experimenting with those early 0.x versions of D.
I agree with your points. I do like to bring Nim up as it uses python like syntax with types and then transpiles to C. You get a fast and small native binary and can choose from 2 different GC or no GC. It has a small, but very active community.
> D has not managed to die when it had so many chances to
One interesting thing about D is that we don't have to answer to anybody, so nobody can kill D other than us. We just keep steadily pushing forward regardless.
> 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.
I don't think that's true. Despite their corporate life support and relatively young ages, Go, Rust and Swift are all in the top 25 most active languages on Github (https://gist.github.com/alysonla/e14c01ec7a0d2823e7317f7b58b...) and D is not (and never has been).
The masses have had a long time to adopt D and I wouldn't get my hopes up simply because it's not dead yet.
The Dcompute kernel language (which for the most part is plain D, the compiler is completely reused) has the usual set of restrictions that any kernel languages have:
no exceptions, recursion, runtime (which is what betterC is about), function pointers.
It still has all the the features that make D great, sane templates (will work across both host and device to a degree), ranges, CTFE (no need to precompile you lookup tables) and so on.
Garbage in, garbage out. Github's language detection isn't perfect, and people in the D community simply aren't particularly focused on marketing and popularity contests. See here for example :
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.
I emphatically disagree that C++11 has made D irrelevant. With C++11, I still have to think about fifty possible ways to do something, old and new, and all of the possible different implications and risks and segfaults I could get with each. I don't have the luxury of ignoring all C++ written before 2011, nor can I ignore all of the design decisions before 2011 that resulted in the current status of C++ features.
After working with C++11 (or C++14 or C++17), D is such a breath of fresh air. Everything is so... easy. I can do what I want, and I don't have to worry about doing just the wrong kind of thing to get a segfault or UB. I might get stack traces at runtime if I make a mistake, or even better, compiler errors because my types didn't check correctly or my compile-time evaluations had errors, but the language is much simpler and cleaner because it's been able to throw out the baggage of C++. In fact, it's thrown it out twice, once for D1 and again for D2, what is now simply called "D".
And being able to actually throw out cruft without concerns for backwards compatibility is why D isn't irrelevant.
> 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... : "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).
> 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.
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.)
I would like to contact Go's "official marketing" department and tell them they have done a horrible job at marketing, because most of the lauding for go comes from developers I know that love getting work done with it!
In any case, I will +1 you on coming from python and ruby, and add another major bucket go developers come from is node js.
Indeed, but as I say in my comment, Go originally foresaw itself replacing C++ as well. The idea that one needed to add a runtime in order to "replace" C++ stems back to the original (and massively successful!) C++ replacement: Java.
> Once the C++11 standardization process took off, D was pushed away into irrelevance.
No doubt about it, many existing C++ users feel this way. I've read the same comment many times. Most programmers, however, are not C++ programmers, and they are not looking for a better C++. They are looking for the best programming language for their needs (which means in most cases they won't go anywhere near C++). Your comment about D being irrelevant doesn't make much sense.
And that's precisely why D fails. D was marketed as nothing more than C++'s successor, right down to the naming choice. No one is looking for a better C++, therefore no one bothers with D.
Meanwhile, those who have to work with C++ keep their eyes in the C++ standardization process. Since D's inception, the C++ standardization committee already produced three standards which oddly enough do include stuff that is sought after by the C++ community.
D was marketed as 'Mars', but for some reason people insisted on calling it 'D' instead, and Walter relented and changed the name of the language.
It's great that C++ is catching up. It's almost got static if, except not because it introduces a new scope. Maybe next time...
The C++ programmers I know are attached to native code, but not exactly content with C++. Ethan Watson of Remedy Games (Quantum Break) said "we are an industry looking for salvation".
> If I'm not mistaken, Rust is being sold as a better C, not C++.
We generally try to market Rust as a good language on its own merits rather than a "better X." That said, there are undoubtably comparisons to make, but the latest iteration of our marketing is "confident, productive systems programming."
D may be a sort of "SpaceX" of languages, designed to improve the competition up to a point it's no longer needed, more or less like Scala did with Java. But even that is a huge success, maybe better than finishing C++ off.
It is usually only way some programmers are forced to adopt new programming languages, in spite they religious beliefs regarding how programming should be.
Notorious example, game developers moving from Assembly to C/Pascal and later from C to C++.
Or systems programmers being force to move into C++ instead staying with C (e.g. IO KIt and UMDF).
Most people I know have not heard of D, but have definitely heard of Go, Swift and (less often, but still frequently) Rust. If in 16 years D has not achieved mass adoption, what is different now, when there are more competitors that offer better features?
It's a big world out there. Would you ever imagine that D would be taking market share from... Extended Pascal? But there's a naval architect who designs great big ships with a 500k sloc codebase he is exploring porting to D. Web guys get the attention but enterprise users are a much bigger world than just that.
If something is growing very quickly then saying it hasn't yet dethroned C, so it won't ever be significant seems to me to be a bit brittle thinking. Compound growth and the passage of time - thats what has been underway for some time now.
I did not compare D to C, but rather to Rust, Swift, and Go. Compared to D, Go already has huge marketshare. Rust, similarly, excels in spaces that D does not endeavor to work in (no-managed-runtime settings), and is beginning to see adoption in areas where performance is critical.
From what I have seen of D, it provides a C++ without some of the cruft, but without trying to solve other issues with C++-like languages (for eg: usefulness of Algebraic Data Types). Why should someone choose D today over Go or Rust for any project? I have yet to see a convincing answer.
> Why should someone choose D today over Go or Rust for any project?
D over Go: D has much better language mechanisms for abstraction and programming in the large.
Go over D: Go has an incremental, mature GC.
Rust and D do not quite target the same application domains (though there's overlap), so it's difficult to compare them. Insofar as they do (D with @nogc and @safe), the tradeoffs become rather complicated.
