But by including the GC/runtime it went into a category with C# and Java which are much better options if you're fine with shipping a runtime and GC. Eventually Go showed up to crowd out this space even further.
Meanwhile in the C/C++ replacement camp there was nothing credible until Rust showed up, and nowadays I think Zig is what D wanted to be with more momentum behind it.
Still kind of salty about the directions they took because we could have had a viable C++ alternative way earlier - I remember getting excited about the language a lifetime ago :D
Furthermore, if you dig deeper, you'll find that D offers far greater control over its garbage collector than any other high-level language, to the point that you can eagerly free chunks of allocated memory, minimizing or eliminating garbage collector stops where it matters.
C# C interop is pretty smooth, Java is a different story. The fact that C# is becoming the GC language in game dev is proving my point.
>Furthermore, if you dig deeper, you'll find that D offers far greater control over its garbage collector than any other high-level language, to the point that you can eagerly free chunks of allocated memory, minimizing or eliminating garbage collector stops where it matters.
Yes, and the no-gc stuff was just attempts to backpedal on the wrong initial decision to fit into the use-cases they should have targeted from the start in my opinion.
Look D was an OK language but it had no corporate backing and there was no case where it was "the only good solution". If it was an actual C++ modernization attempt that stayed C compatible it would have seen much better adoption.
True, but you still need to either generate or manually write the bindings. In D, you just import the C headers directly without depending on the bindings' maintainers.
> If it was an actual C++ modernization attempt that stayed C compatible it would have seen much better
Any D compiler is literally also a C compiler. I sincerely don't know how can one be more C compatible than that.
> Yes, and the no-gc stuff was just attempts to backpedal on the wrong initial decision
I think that it was more of an attempt to appease folks who won't use GC even with a gun to their head.
Are there technical reasons that Rust took off and D didn't?
What are some advantages of D over Rust (and vice versa)?
D retains object-oriented programming but also allows functional programming, while Rust seems to be specifically designed for functional programming and does not allow OOP in the conventional sense.
I've been working with D for a couple of months now and I noticed that it's almost a no-brainer to port C/C++ code to D because it mostly builds on the same semantics. With Rust, porting a piece of code may often require rethinking the whole thing from scratch.
Is this a Walter Bright alt? I've seen him use the cowboy programmer term a few times on the forum before.
As someone who considered it back then when it actually stood a chance to become the next big thing, from what I remember, the whole ecosystem was just too confusing and simply didn't look stable and reliable enough to build upon long-term. A few examples:
* The compiler situation: The official compiler was not yet FOSS and other compilers were not available or at least not usable. Switch to FOSS happened way too late and GCC support took too long to mature.
* This whole D version 1 vs version 2 thingy
* This whole Phobos vs Tango standard library thingy
* This whole GC vs no-GC thingy
This is not a judgement on D itself or its governance. I always thought it's a very nice language and the project simply lacked man-power and commercial backing to overcome the magical barrier of wide adoption. There was some excitement when Facebook picked it up, but unfortunately, it seems it didn't really stick.
1. D had a split similar to python 2 vs 3 early on with having the garbage collector or not (and therefor effectively 2 standard libraries), but unlike python it didn't already have a massive community that was willing to suffer through it.
2. It didn't really have any big backing. Rust having Mozilla backing it for integration with Firefox makes a pretty big difference.
3. D wasn't different enough, it felt much more "this is c++ done better" than it's own language, but unlike c++ where it's mostly a superset of c you couldn't do "c with classes" style migrations
Of course you can make codegen as part of your build process with any language, but that can be kludgy (and often limited to a single project).
My (somewhat outdated) experience is that D feels like a better and more elegant C++. Rust certainly has been influenced by C and C++, but it also took a lot of inspiration from the ML-family of languages and it has a much stronger type system as a consequence.
Many of us believe on automatic memory management for systems programming, having used quite a few in such scenarios, so that is already one thing that D does better than Rust.
There is the GC phobia, mostly by folks that don't get not all GCs were born alike, and just like you need to pick and chose your malloc()/free() implementation depending on the scenario, there are many ways to implement a GC, and having a GC doesn't preclude having value types, stack and global memory segment allocation.
D has compile time reflection, and compile time metaprogramming is much easier to use than Rust macros, and it does compile time execution as well.
And the compile times! It is like using Turbo Pascal, Delphi,... even thought the language is like C++ in capabilities. Yet another proof complexity doesn't imply slow compile natives in a native systems language.
For me, C# and Swift replace the tasks at work were I in the past could have reached for D instead, mostly due to who is behind those languages, and I don't want to be that guy that leaves and is the one that knew the stack.
The problem is the term "systems programming". For some, it's kernels and device drivers. For some, it's embedded real-time systems. For some, it's databases, game engines, compilers, language run-times, whatever.
There is no GC that could possibly handle all these use-cases.
Right now, you'd have to switch languages.
But in a Great Language you'd just have to refactor some code.
Yes. D tried to jump on the "systems programming with garbage collection" dead horse, with predictable results.
(People who want that sort of stupidity already have Go and Java, they don't need D.)
Go wasn't around when D was created, and Java was an unbelievable memory hog, with execution speeds that could only be described as "glacial".
As an example, using my 2001 desktop, the `ls` program at the time was a few kb, needed about the same in runtime RAM and started up and completed execution in under 100ms.
The almost equivalent Java program I wrote in 2001 to list files (with `ls` options) took over 5s just to start up and chewed through about 16MB of RAM (around 1/4 of my system's RAM).
Java was a non-starter at the time D came out - the difference in execution speed between C++ systems programs and Java systems programs felt, to me (i.e. my perception), larger than the current difference in performance between C++/C/Rust programs and Bash shell scripts.
I don't even know what that term means anymore; but afaik Java didn't really have reliable low-level APIs until recently.
After all, D is supported by GCC and Clang and continually being maintained, and if updates stopped coming at some point in the future, anyone who knew a bit of C / Java / insert language here could easily port it to their language of choice.
Meanwhile, its syntax is more expressive than many other compiled languages, the library is feature-rich and fairly tidy, and for me it's been a joy to use.
The team is quite small and mostly volunteers, so there is the question how long can Walter Bright keep at it, and who will keep it going afterwards when he passes the torch.
https://www.youtube.com/playlist?list=PLpM-Dvs8t0VZn81xEz6Ng...
Also, this presentation https://accu.org/conf-docs/PDFs_2007/Alexandrescu-Choose_You... killed a lot of bike shedding!
Say your starting a new Staff Engineer or Tech Lead job. What gets you to convince a CTO that we need to have a team learn D ?
On the flip side, where are the 200k base salary D positions.
Get me an interview in 2 months and I'll drop 10 hours a week into learning
The latest release [1] was on Jan 7th, and it contains more updates than, say, the latest release of Dart, which has one of the largest corporations behind it.
A language with sane Compile Time features (Type Introspection, CTFE, mixins, etc)
A language that can embrace C ecosystem with sane diagnostics
A language that ships with its own optimizing code generator and inline assembler!
A compiler that compiles code VERY fast
A compiler with a readable source code that bootstraps itself in just 5 seconds
People who dunk on it "bEcAuSe iT Is nOt MaInsTrEaM" are clueless
> This very post is probably his too, under an alt :)
The probability of that is virtually zero. Walter is a principled person, has better things to do, and his writing style is vastly different from the OP's.
At the same time, I've never used it, I'm not sure why.
Anyway, the author of D language is here on HN (Walter Bright).
Ownership and borrowing are so much less baroque in D than in Rust. And compile times are superb.
In a better world, we would all be using D instead of C, C++ or Rust.
However in this age of Kali...
Pointers are not the only 'pointer's to resources. You can have handles specific to your codebase or system, you can have indices to objects in some flat array that the rest of your codebase uses, even temporary file names.
An object oriented (or 'multi paradigm') language has to account for these and not just literal pointers.
This is handled reasonably well both in Rust and C++. (In the spirit of avoiding yet another C++ vs Rust flamewar here, yes the semantics are different, no it doesn not make sense for C++ to adopt Rust semantics)
The reason for that is OOP tends to favor constructs where each objects holds references to other objects, creating whole graphs, its not uncommon that from a single object, hundreds of others can be traversed.
Even something so simple as calling a member function from a member function becomes incredibly difficult to handle.
Tbh - this is with good reason, one of the biggest flaws of OOP is that if x.foo() calls x.bar() in the middle, x.bar() can clobber a lot of local state, and result in code that's very difficult to reason about, both for the compiler and the programmer.
And it's a simple case, OOP offers tons of tools to make the programmers job even more difficult - virtual methods, object chains with callbacks, etc. It's just not a clean programming style.
Edit: Just to make it clear, I am not pointing out these problems, to sell you or even imply that I have the solution. I'm not saying programming style X is better.
When commandline apps were everywhere, people dreamed of graphical interfaces. Burdened by having to also do jobs that it was bad at, the commandline got a bad reputation. It took the dominance of the desktop for commandline apps to find their niche.
In a similar way, OOP is cursed by its popularity. It has to become part of a mixed diet so that people can put it where it has advantages, and it does have advantages.
I have ported Ray Tracing in One Weekend into Rust, while keeping the same OOP design from the tutorial, and affine types were not an impediment to interfaces, polymorphism and dynamic dispatch.
That's more a problem of having mutable references, you'd have the same problem in a procedural language.
In diehard FP (e.g. Haskell) it's hard to even place a breakpoint, let alone see the complete state. In many cases, where implementing a piece of logic without carrying a lot of state is impossible, functional programming can also become very confusing. This is especially true when introducing certain theoretical concepts that facilitate working with IO and state, such as Monad Transformers.
Imho, most FP languages have very serious human-interface issues.
It's no accident that C likes statements (and not too complex ones at that). You can read and parse a statement atomically, which makes the code much easier to read.
In contrast, FP tends to be very, very dense, or even worse, have a density that's super inconsistent.
I agree with the sentiment, I really like D and find a missing opportunity that it wasn't taken off regarding adoption.
Most of what made D special in D is nowadays partially available in mainstream languages, making the adoption speech even harder, and lack of LLM training data doesn't help either.
I actually think that the average D code produced has been superior to the code produced for the C++ problems I tested. This may be an outlier (the problems are quite different), but the quality issues I saw on the C++ side came partially from the ease in which the language enables incompatible use of different features to achieve similar goals (e.g. smart_ptr s new/delete).
That shouldn't stop any self-respecting programmer.
Those that learn to do robot maintenance, are the ones left at the factory.
Enterprise CMS deployment projects have already dropped amount of assets teams, translators, integration teams, backend devs, replaced by a mix of AI, SaaS and iPaaS tools.
Now the teams are a fraction of the size they used to be like five years ago.
Fear not, there will be always a place for the few ones that can invert a tree, calculate how many golf balls fit into a plane, and are elected to work at the AI dungeons as the new druids.
I'm sorry, what? Are you suggesting that Ikea made carpenters obsolete? It's been less than 6 months since last I had a professional carpenter do work in my house. He seemed very real. And charged very real prices. This despite the fact that I've got lots of Ikea stuff.
Which is it? Carpenters or furniture makers? Because the two have nothing in common beyond the fact that both professions primarily work with wood. The former has been unaffected by automation – or even might plausibly have more demand due to the overall economic activity caused by automation! The latter certainly has been greatly affected.
The fact that people all over the thread are mixing up the two is mindboggling. Is there a language issue or something?
The irony in this statement is hilarious, and perfectly sums up the reality of the situation IMO.
For anyone who doesn't understand the irony: a carpenter is someone who makes things like houses, out of wood. They absolutely still fucking exist.
Industrialised furniture such as IKEA sells has reduced the reliance on a workforce of cabinet makers - people who make furniture using joinery.
Now if you want to go ask a carpenter to make you a table he can probably make one, but it's going to look like construction lumber nailed together. Which is also quite a coincidence when you consider the results of asking spicy autocomplete to do anything more complex than auto-complete a half-written line of code.
I think _you_ have misunderstood what a carpenter is. At least where I live, you might get a carpenter to erect the wood framing for a house. Or build a wooden staircase. Or erect a drywall. I'm sure most carpenters worth their salt could plausibly also make wooden furniture, at an exorbitant cost, but it's not at all what they do.
I sanity checked with Wiktionary, and it agrees: "A person skilled at carpentry, the trade of cutting and joining timber in order to construct buildings or other structures."
Carpenters make many things besides houses.
See the section "Types of carpentry".
Which the discussion seems to imply it kind of works, but not without a few pain points.
Edit: Instead of downvoting, just answer the question if you've upvoted it. But I'm guessing it's the same sock accounts that upvoted it.
HN isn't as homogeneous as you think. By this measuring stick, half of the posts on the front page can be put into question every day.
We also know there are tons of sock accounts.
And no half of the posts on front page can't be put in that since they aren't constantly reposted like this.
So, while there are a few people who will have learnt about this for the first time. Most of you know what it is and somehow feel like this is your chance to go look I'm smarter than Iain. And I think you've failed again.
That's why some things get reposted and upvoted. In hope of getting someone else to understand them.
By the way, do you complain about sock accounts when yet another "Here is this problem, and by the way we sell a product that claims to solve it" gets upvoted?
Nope. That's not a joke. That's not funny.
> That's why some things get reposted and upvoted. In hope of getting someone else to understand them.
No, they get reposted and upvoted by sock accounts in hope that someone will finally be interested in a 30 year old programming language.
> By the way, do you complain about sock accounts when yet another "Here is this problem, and by the way we sell a product that claims to solve it" gets upvoted?
What does content marketing have to do with sock accounts?
I'm honestly not sure what point you thought was getting made. Do you honestly think people don't understand D? It's been looked at repeatedly and still nothing cool is built in it.
To me, a C guy, the focus on garbage collection is a turn-off. I'm aware that D can work without it, but it's unclear how much of the standard library etc works fine with no garbage collection. That hasn't been explained, that I saw at least.
The biggest problem however is the bootstrapping requirement, which is annoyingly difficult or too involved. (See explanation in my other post.)
Problem identified.
That's not popular here.
meta
Also, do you know it only gets to front page if the hardcore that go to new upvote it? How many hardcore people don't know what D is?
I think there's also something called ImportC. Not sure what that is either.
I read the D blog sometimes, and have written some programs in D, but am not quite clear about these two terms.
https://dlang.org/spec/importc.html
> Note: ImportC and BetterC are very different. ImportC is an actual C compiler. BetterC is a subset of D that relies only on the existence of the C Standard library. BetterC code can be linked with ImportC code, too.
D contains an actual C compiler because Walter Bright wrote one long ago and then incorporated it into D.
Zig also contains an actual C compiler, based on clang, and has a @cImport directive.
To get it onto one's system, a bootstrapping step is required. Either building gcc 9 (and only gcc 9) with D support, then using that gcc to bootstrap a later version, or bootstrapping dmd with itself.
In the former case I'm already having to bootstrap Ada onto the system, so D just adds another level of pain. It also doesn't support all the same architectures as other gcc languages.
In the case of dmd, last I checked they just shove a tarball at you containing vague instructions and dead FTP links. Later I think they "updated" this to some kind of fancy script that autodownloads things. Neither is acceptable for my purposes.
I just want a simple tarball containing everything needed with clear instructions, and no auto downloading anything, like at least 90% of other packages provide. Why is this so hard?
Tip: pretend it's still the BBS days and you are distributing your software. How would you do it? That's how you should still do it.
I haven't tried the LLVM D compiler, and at this point quite frankly I don't want to waste any more time with the language, in its current form at least--with apologies to Walter Bright, who is truly a smart and likeable guy. Like I said, it's regrettable.
The only way to revive interest in D is through a well planned rebranding and marketing campaign. I think the technical foundation is pretty sound, but the whole image and presentation needs a major overhaul. I have an idea of how to approach that, were there interest.
The first step would be to revive and update the C/C++ version of the D compiler for gcc so as to remove the bootstrapping requirement and allow the latest D to be built, plus a commitment to keeping this up to date indefinitely. It needs to support all architectures that GCC does.
Next, a rebranding focused on the power of D without garbage collection.
I'm willing to offer ongoing consultation in this area and assistance in the form of distro support and promotion, in exchange for a Broadwell or later Xeon workstation with at least 40 cores. (Approx $350 on Ebay.) That's the cost of entry for me as I have way too much work to do and too few available CPU cycles to process it.
Otherwise, I sincerely wish the D folks best of luck. The language has a lot of good ideas and I trust that Walter knows what he is doing from a technical standpoint. The marketing has not been successful however, sadly.
Is a strange claim, and hard to cite. But I think many HNers have tried out D and decided that it's not good enough for them for anything. It is certainly advertised hard here.
Maybe you should Ask HN.
I think any presumption about what "we all know" will earn you downvotes.
Never has an old language gained traction, its all about the initial network effects created by excitement.
No matter how much better it is from C now, C is slowly losing traction and its potential replacements already have up and running communities (Rust, zig etc)
You can code your quines in whatever you'd like, but a serious project needs existence of good tooling, good libraries, proven track record & devs that speak the language.
There are serious projects being written in D as we speak, I'm sure, and the language has a track record of having been consistently maintained and improved since 2001, and has some very good libraries and tooling (very nice standard library, three independent and supported compiler implementations!) It does not have good libraries and tooling for all things; certainly integrations with other libs and systems often lag behind more popular languages, but no programming language is suitable for everything.
What I'm saying is there's a big world out there, not all programmers are burdened with having to care about CV-maxxing, community or the preferences of other devs, some of them can just do things in the language they prefer. And therefore, not everything benefits from being written in Rust or whatever the top #1 Most Popular! Trending! Best Choice for System Programming 2026! programming language of the week happens to be.
But the real explosion happened with ML.
For example, python got a similar boost in popularity in the late 2000s and early 2010s when almost every startup was either ruby on rails or django. Then again in the mid 2010s when "data science" got popular with pandas. Then again in the end of 2010s with ML. Then again in the 2020s with LLMs. Every time people eventually drop it for something else. It's arguably in a much better place with types, asyncio, and much better ecosystem in general these days than it was back then. As someone who worked on developer tools and devops for most of the time, I always dread dealing with python developers though tbh.
Out of curiosity, why is that?
Containers have certainly helped a lot with python deployments these days, even if the Python community was late to adopt it for some reason. throughout the 2010s where containers would have provided a much better story especially for python where most libraries are just C wrappers and you must pip install on the same target environments, python developers I dealt with were all very dismissive of it and just wanted to upload a zip or tarball because “python is cross platform. It shouldn’t matter” then we had to invent all sorts of workarounds to make sure we have hundreds of random system libs installed because who knows what they are using and what pip will need to build their things. prebuilt wheels were a lot less common back then too causing pip installs to be very resource intensive, slow and flaky because som system lib is missing or was updated. Still python application docker images always range in the 10s of GBs
I started using Python in version 1.6, there were already several O'Reilly books, and Dr.Dobbs issues dedicated to Python.
Also, many languages that see a lot of hype initially lose most of their admirers in the long run, e.g. Scala.
Python?! Created in 1991, became increasingly popular – especially in university circles – only in the mid-2000s, and then completely exploded thanks to the ML/DL boom of the 2010s. That boom fed back into programming training, and it's now a very popular first language too.
Love it or hate it, Python was a teenager by the time it properly took off.