I was sad that D never took off. I had high hopes that it would eventually replace C++ for my professional development. D was a language that really enabled functional programming, and I mean real functional programming while retaining the low level control of C.
We learned a lot from pushing D, and now I am working full time as a Rust developer. Rust doesn't have everything D has, but it also has plenty that D doesn't have and it's still in the same spirit of safer, more expressive C++ with the same efficiency. I hope that D developers will check out Rust and try to push a single front, I think it has a better chance of knocking C++ off its pedestal.
>Rust doesn't have everything D has, but it also has plenty that D doesn't have and it's still in the same spirit of safer, more expressive C++ with the same efficiency.
And no GC, which is major for my hopes that it might be a viable alternative for us forgotten embedded programmers out there. LLVM seems to be a good backend for getting more embedde support in the future as well.
Rust for me has almost everything I expect from a "better C++", the Cargo project management is stellar, rustup is great for staying up to date, integrated testing and benchmarking is amazing. I just find there's still a lack of crates which should solve itself over time and a bit of a lack of good documentation (outside of the basic Rust language resources most crates are very hard to understand looking at docs.rs, which is especially sad given how well integrated documentation is).
There's lots of great stuff for embedded in Rust now too, you can no_std and use core, the new panic stuff. IMO it's awesome to write a language and do some more 'advanced' type stuff like add compile time safety with phantom types and stuff have it compile and run on an embedded device. The interesection of features there is great.
The critical faults with D that prevented it from displacing C* were that it relied on a GC by default and that it wasn't open source. Things might have played out much differently had they addressed these issues early on.
* aside from inertia, but older languages also had inertia once.
The only issue with the GC is the implementation could get some improvements.
Mesa/Cedar, Oberon and its variants, Modula-3, Sing# and System C# might have fallen, but we still have Swift, Go, .NET Native/C# 7.3, Kotlin/Native, Nim, Crystal and Chapel, besides D.
Not all hope is lost for those of us that belive on system languages with GC support.
> The only issue with the GC is the implementation could get some improvements.
jake_the_third's point was that until relatively recently, it wasn't practical to use D without using its GC. Some folks don't want GC. Some proportion of them have good reasons.
And the BSDs have mostly moved passed the era of legal ambiguity that plagued them early in their development. For better or worse, timing and initial impressions count.
I actually like that it has a GC, it has made programming in D easier and more accessible for me. It's also a simple GC that you can force to behave if you know how. D has the @nogc attribute for the situations where one would want to disable the GC and use something else.
D is faster to compile, 3 backends, easier to start with, more expressive metaprogramming, optional runtime and GC, compile-time duck typing, Visual Studio debugger, grassroot "agnostic" community, very pleasurable and productive language. Companies have built their entire infrastructure on it, to great success.
I think there's a subtle fallacy about functional programming vs low level. Mostly due to the usual benefits of garbage collection style of memory management. But I find stack languages very functional in nature, it's when things grow and you start using lots of data structures that you lose sight of fp principles. Especially if you consider that FP Map/Reduce will be provably compiled to a cute choreography of localized (globally invisible) side effects. I'd like to claim that pre 80s programmers were doing a lot of that by hand without thinking about it.
DMD has the fastest compilation times and gets new features right away. LDC will produce faster code for the times that you need to maximum performance. GDC takes longer to add new features than either DMD or LDC, but it produces fast code.
In my experience, gdc has produced faster code than ldc for my problems. This is subjective, so please don't ask me to produce benchmarks. I just remember gdc outperformed ldc in some cases, that's all.
Ain't it great to have a choice? Each has their strengths and weaknesses, and have different feels. Just install all three, and see which one suits your style best.
This is literally what stopped me from learning D a few years ago. I started reading about it, got intrigued, did some tutorial-style stuff, decided to try it on a real project, and then realize that meant having to figure out which toolchain or choice of standard lib to use, and just gave up and used c++ as usual.
If I was already familiar with the tradeoffs, or if I was very motived to learn D, I'm sure this wouldn't have been a big obstacle. There were plenty of resources explaining the difference and I'm sure there are more now. I'm just saying, anecdotally, that this was the roadblock for me.
Interesting, I saw it the other way at least there is no single supplier...The best way I found to think of it was (though your mileage may vary with the analogy):
DMD - gave latest features - its the shiny concept super car reference that shows whats coming next..
LDC - is the production sports car -integrates with rest of LLVM - and occasionally surprises with innovative features like Nicholas Wilson's brilliant D-compute.
GCC - its the production workhorse, fits all pipelines, goes where you need it and does it with style - its the muscle car of D world.
You pick the one that meets what you need/want.
Ian Buclaw has really done a superb job piloting this into GCC and hopefully GCC support might get you to look at D again :-).
It's not so much different compilers, I don't remember the specifics, but at the time the impression I got was that each one had a very different standard library, so it would be hard to move from one to another. Maybe that's not the case anymore, or maybe I was mistaken.
In any case, thats a good analogy, and I'll try to find an excuse to take another look at D. Having gcc support does sound like it would make things easier. Thanks.
Imagine you don't already know this though, to really make an informed choice you have to put in all the research just to know the answer to a very simple decision.
yup, like it or not highly opinionated languages like Golang actually make beginners feel more comfortable as they're not confronted with choices they don't know they answers to at every turn
At the time I was super enthusiastic to try out (many years ago at this point), it wasn't open source so I decided to wait it out.
Later, I decided to try it out again, but I had to choose between Phobos and Tango. I didn't have time to evaluate them so I bought a book on Tango. I shelved it because it seemed like a lot of stuff was still changing.
When I tried again a couple of years later I wasn't sure whether to use DMD, GDC, or LDC. I didn't have the time to evaluate the compiler implementations, I just wanted to poke at it and try it out, and wanted to look at a bunch of examples before I jumped in. Three compilers made it a pain in the butt so I put it on the backburner and forgot to ever come back.
At this point D had asked too much of me to figure out how I wanted to use it, three times over, and I wasn't about to commit myself to researching the implementations instead of just hacking so I abandoned D despite initially falling in love with it. By that point, other good native C++ alternatives had matured - Go, Rust, and Swift – for different use cases.
After giving it three shots to give me a simple and consistent development experience I'll probably never try D again.
Meanwhile, Rust has one compiler and I have multiple choices of IDEs which all support the toolchain - I just set it and go and it tends to do just what I want because all that common surface area in the Rust community gets improved for everyone.
D is a great language hampered by a depressingly frustrating developer experience, and as such until that changes it is deeply hurting its own competitiveness with everyone who isn't committed to using it and making it work for them right off the bat (many many people).
I also know one FAANG company that invested in D is seeing a very noticeable shift towards Rust instead.
As category theory teaches us, there is a duality to a choice. If you are constructing value of a sum type you can choose any variant, but the one who receives it should be able to handle any possible variant. If you are using a library you can choose any compiler, but author of that library should ensure that it works with all compilers. If someone has a choice, then in some other place there is more complexity or work to be able to handle that choice.
Indeed. But a new version of DMD gets released with every update of the front-end, those then get slowly merged into LDC, and even more slowly into GDC. Last time I checked a lot of my code and it's dependencies don't compile on anything except DMD.
* Better feature stability,
* Robust and well-defined standards,
* improved security,
* better debugging options,
* and most importantly competitive pressure.
Just look at how LLVM pressured GCC into shape. I'm primarily a GCC user, but I'm very very grateful for LLVM's existence. Also multiple equally competent compilers disincentivise them from going rouge (e.g. .net telemetry).
Weighing the pros against the cons, I'd have to stand with GP in saying that choice is good.
I remember that - _many_ years ago, ten maybe? - when I tried to use D for OS development, I was forced to use GCC because it was the only one who supported custom linker scripts IIRC. Nice to see that all the projects are still doing well!
DMD offers the newest features and is the easiest to get started with. So it's the beginner recommended option. GDC tends to compile the fastest/most optimized executables but lags behind the most in features.
LDC was my preferred frontend, when I coded D. It meets DMD and GDC in the middle with well optimized output code whilst being close to bleeding edge.
GCD is the greatest common divisor, and D is the language with the greatest common set of features relative to the set of languages that the gcc suite can compile. So in many ways it is an equivalent to the GCD.
Uhh no, not really, GNU doesn't "require C or C++". First of all GNU coding standard says C is the most recommended language, not C or C++. It even suggests Java before C++ (but I suspect that's a relic of old GNU AoT Java compiler?) and requests people not to use templates (which is hardly what we call C++ nowadays). Other than that, it's 100% ok to write a GNU package in any language people can generally understand and there is a free implementation available, like python, lisp etc. Scheme (via GNU Guile) is even the "official extension language" of GNU and emacs (one of the more popular and older GNU packages) is mostly written in lisp.
You must also understand that GNU optimizes for masses to understand the source code, and GNU coding standard was written when C was a very popular language and investing in any other language would just be a gamble. Imagine GNU being written in TCL or Ada... C was and still is a safe choice if you want a good deal of people to understand your code decades later.
D is a nice language. It has a wide range of features, but one can get started with it without learning all of them.
Here are a handful of D programs that use various features of the language and some of its libraries, on my blog. Most of them are simple command-line utilities to do various things. Readers may find them of use to get a flavor of the language and to know some of the kinds of things it can be used for.
I used the DMD compiler to compile and run them on Windows.
A few of the posts are about interviews too.
Don't miss the interview where the creators or key people from the C++, Rust, D and Go languages talk to each other on a panel about some of the pros and cons of their respective languages - and incident near the end of the video, involving Bjarne Stroustrup (the LangNext video below).
I appreciate it when you folks do this. But the UX for the reader isn't great, in that I must separately open your link to see the contextual parent of the split thread.
Perhaps you can prefix the split post's content at the same indentation level as its own content with something like Moderator-edit: Split from $URL as offtopic, original parent was: $PARENT or somesuch would help.
That's a little better, yes. But what would be really nice is a way to see the parent of the split inline, without having to follow a link at all.
In effect, the problem is that quoting and threading solve the same problem: giving the reader context. The original author's post relied entirely on threading, which you broke by splitting off the discussion. I think that adding a quote to the split post would restore context.
There is some risk that by selectively quoting, you are becoming an editor rather than just a moderator. The part that is relevant for this particular split is obvious, but that won't always be true, so there should be some mechanism to show that you as a moderator accept responsibility for any misquoting. You could indicate the quote with italics and some very brief text explaining that you as a moderator put the quote in there. Or you could set it off with a thin orangered boarder, perhaps.
I think what GP means is make the anchor links easier to find, such that one can right-click somewhere in the UI and copy an anchor link to a comment. I'm not aware that they're available anywhere, presumably you constructed the anchor link manually, or examined the source?
I think you detached it backwards? Surely the part you linked to should be in the main thread (The D Language Front-End Merged Into GCC 9), while the discussion of "indefatigable" should be split off into another thread?
They're both still in the same overall thread, but detaching the off-topic bit from its parent allows it to sink to the bottom of the page. Does that make sense?
Nice, for me it was a new word as well, even tho it was largely understandable by the radicals (in-/un- and fatig- + able)
What I wonder is:
(?) Is OP a native English speaker and is this word used in daily contexts,
(or?) did he use it because he might not be an English speaker and he searched for the words in his own language and that is the word that came out, instead of the more common "tirelessly".
(or?) he is a native speaker and he knows this word is not used in daily/common conversations... so, by using this different concoction, did he meant to translate some additional feeling? is "indefatigable" a stronger "tirelessly"?
I know it's oddly specific but I am not a native speaker and insight into these odd ducks helps me build a maturer mind model of it all.
I'm guessing the first. I'm a native speaker and I know this word. I don't use it in speaking (it's a bit if a mouthful), but I use it occasionally in writing.
I think it has better imagery. When I hear "tireless", I think of being tired, but forcing myself to stay awake. When I hear "indefatigable", I think of someone playing sports or going on a long journey and pushing through the physical exhaustion.
So yeah, a bit of the first and a bit of the third most likely. Walter Bright is the author of the D language, so I expect him to be intimately aware of the effort required, hence the more vivid imagery.
I don't recall ever hearing the word, but it appears a lot in books I've read, even recently written ones.
"indefatigable" fits what I wanted to convey better than "tirelessly". From the Cambridge English Dictionary:
"always determined and energetic in trying to achieve something and never willing to admit defeat"
Iain has had a plethora of reasons to abandon the project, and nobody would have blamed him. But he's persisted in the face of little encouragement, less support, and lots of complaining. It's a massive achievement. Indefatigable is the perfect word.
It's an odd word, isn't it? I can't speak for the inimitable Walter Bright, but I suspect many English speakers like myself enjoy the pure sound of it - so many consonants in such a short space of time. Somewhat difficult to pronounce, slightly archaic, it perhaps confers a little more kudos than commoner alternatives. (And thoroughly deserved kudos, in this case!)
They also use names that seem bad choices today such as Inconstant, Inflexible and Terrible (that word changed meaning over the centuries. Originally, it meant “terror-inducing”. https://en.wikipedia.org/wiki/HMS_Terrible lists eight ships with that name, going back to 1694, so I guess that stil was the intended meaning for the one from 1944)
Consider terror, terrible and terrify! The second word now generally means something like a rubbish or bad state and the third means to induce a state of the first word (bowel quaking, etc etc).
The word dreadful (almost certainly also a warship name) has not suffered quite such an ignominious decline but "I'm dreadfully sorry" is quite often seen in the wild.
I really enjoy words like that. If I haven't seen it before, or it's been a while since I've seen it used, I need to take a bit of extra time to read and decode it.
It also reminds me of words like 'irreparable', rolls off the tongue quickly.
Now, when I hear someone use the word 'extant', especially during spoken language, I immediately think it's pretentious.
The idea of word use being pretentious is self-absorbed and anti-intellectual. I occasionally use the word "extant" because it's part of my vocabulary and is the best word to express its meaning, not to impress people that I don't even know exist prior to their complaint that using some word that is unfamiliar or uncommon to them is "pretentious".
The GURPS role playing system uses the term indefatigable as part of its game mechanics. Additionally, the Film Reroll Podcast uses GURPS as their game system. My guess is that OP either has played GURPS or listened to the Film Reroll.
Also OP could just be really well read.
Personally, I'm glad to see indefatigable in the wild (at least more in the wild than a game system and a pod cast). I think the word is really cool and I haven't found an opportunity to use it myself.
I think some of the third option, and also it’s fun to go to the trouble of digging out a lesser known word from the depths of your dictionary/brain to show just how much you appreciate something.
As another data point, I'm a native English speaker, and I hadn't heard the word before, but I was able to figure out the meaning (which I confirmed by googling it)
We learned a lot from pushing D, and now I am working full time as a Rust developer. Rust doesn't have everything D has, but it also has plenty that D doesn't have and it's still in the same spirit of safer, more expressive C++ with the same efficiency. I hope that D developers will check out Rust and try to push a single front, I think it has a better chance of knocking C++ off its pedestal.