At least Walter, and presumably others in the D leadership, are active here. There's a good chance they will see your comments. This is just a reminder that they are human, too, they care a lot about D, and in my experience they are basically decent people who are trying their best.
More than 20 years passed and nothing really changed. What makes you think it will be different now. It's a "Tango" part 2 all over again. Except now, the ship has long sailed.
While true, and I agree that everyone is human, Walter isn't the only one here who cares about D. If the project would thrive under different leadership then that's something that needs to be considered. I for one really hope for a D comeback, it's by far my favorite language. It's not an attack against Walter, or anyone else. Just people trying to save something that they love.
Unfortunelly this was bound to happen, after so much remarks on forking D throughout the years.
Almost everything I liked in D when Andrei Alexandrescu's book came out in 2010, have made its way to C#, Java, C++.
Yeah, maybe the implementation isn't as nice as in D, but that hardly matters when the implementation is available in some form, with much better tooling and library ecosystem.
Too many years lost chasing the golden feature that would bring people in, without stabilitizing those features.
Even Andrei is nowadays apparently mostly busy with C++ and CUDA than D.
And then there is the whole compile to native programming languages renaissance from the last decade, adding even more competition.
Which is a pity, as the community itself is full of great folks to talk with.
I witnessed a similar case while touring D as an outsider. When Rust was new and the concept of lifetime was brought to the D community, it was deemed unnecessary by Walter. A few years later, he brought his own lifetime proposal that is sufficiently different to Rust's and thus even less verified compared to the previous suggestion from the community. Now that I lost my interest in D, I'm not sure of the maturity of the new lifetime feature, but I would be surprised if it is as useful as Rust's.
I'm not too familiar with either Rust's or D's approach to lifetimes, but from some quick forum searching, it appears that adding Rust-like lifetimes to D would have required significant changes to the design of the language. Every potential feature has tradeoffs in terms of how it interacts with other language features, adds cognitive overhead, decreases compilation speed, complicates the design of the standard library, breaks backward compatibility, etc. I don't think it's reasonable to expect a large-scale overhaul just to support one feature you like from another language.
New governance models start with discussions about governance by a quorum of interested parties, not by dictating a new set of features or the decision to leave some out. That's just a change of regime, not a change of model.
I'm sure that there are legitimate gripes and D's reliance on Walter as gatekeeper may be too strict for some but the way this fork has started out doesn't bode well for the long term. Forks succeed only if they are carried broadly, you'd need to more or less pull a majority of the folks in the D community along rather than just a handful of prolific but ultimately low in number individuals because there is a fair chance that both your fork will fail and that you further fragment the mindshare of the original to the point that it too looses any viability that it still had.
You also need to be able and willing to support it for decades.
Personally, I think it’d have been more fun if they named it ‘Died’ — you get the benefits of sweet taglines “It never Died,” a statement about it being a fork, and the permission to take the language in new directions if that makes sense in the future. OpenD implies full compatibility, etc..
clarify: the big thread referenced here is started by the people doing the forking (2 people so far), and there's a fair amount of good detailed response by D people which is lacking in TFA above. The orig article is just beefing about personalities, and this link has more technical discussion
sounds from this like the people forking basically want a different language, for which they're willing to make a number of breaking changes.
Personally, it's confusing to me what D's niche would be if they go all in on the GC. I get that it didn't really have a solid niche before either, because it was basically just a 10% better C++, without any really distinguishing killer feature, so it was kind of a hard sell, because most people are either going to stick with C++ for the existing support and code bases and industry, or are going to use Rust for greenfield projects, or Zig if they want simplicity, especially since with C++ 20 a 10% better C++ already exists, but I don't think focusing on having a garbage collector really helps so much? All this means is that it's going to be competing with C# and Java, which are already the garbage collected, safe, streamlined C++ successors and have been intended to be such since their inception, and I don't see how you can really compete with either of those languages at this point. Especially C# with its actually pretty excellent low level and unsafe capabilities like raw pointers and control over whether things are reference or value types and control over the layout of things in memory and stuff like that, combined with its pretty okay (for an OOP first language of its age) type system and reflection and all of the ML family features it's been getting.
Honestly, I've always felt really confused about what D's vision is. I've tried reading some of the docs about certain language features like better see and safe mode and lifetimes and they've been grammatically just kind of hard to read and generally poorly explained, despite going into great detail on things, and I've never really been able to get a sense for a coherent design vision or purpose for the language. The author mentions that this has been a problem, but I don't feel their vision is really any clearer. Yes they have a few concrete midterm technical goals, which is great, but it isn't clear to me what those goals are in service of. Honestly, I'm a rust programmer, so you know what I do for Greenfield personal projects, but I'd rather just use OCaml, C++, or even C# if I had to pick something else.
In the last decade, we've had many learning experiences around governance of programming languages.
Most of the changing languages that come to mind, I realize, that they, too, had a big upset or oops related to governance.
I now think one of the key things to look for in a programming language is governance -- what they say about how they do it, what they actually do, how that's working out so far, and how you think that will work out in the future.
While I agree this is an important problem, I don't think there is a satisfactory answer. Programming language evolution is more or less a complexity management, while you also have to balance requirements from various stakeholders. Almost all governance drama came from one group of stakeholders complaining about requirements essential for other group of stakeholders, and you can't always satisfy both. (Rust `async` for example is known to be such case, explaining a functioning but generally unsatisfactory design.) Go is a rare exception where the core team had no reason to honor all stakeholders and enough resource and willpower to do so, and yet some drama did happen.
I fail to see any negative aspects of having multiple compiler implementations around.
IMHO that's the main reason why C became so popular, compilers are free to explore into different directions, language extensions that have proven their worth will eventually be picked up by other implementations, and sometimes even make it into the standard without being butchered too much by the committee agreement process.
As a contrary perspective, a language which enthusiastically welcomes patches from anyone is likely to degenerate into an incoherent mess very quickly.
Language design is difficult. Features interact in complicated ways. Fixing mistakes is tricky - you break existing code.
Forking D sounds fine. It's easier to start with an implementation than to go from scratch. Ideas which work out well get to have a existence proof when proposing them to the original. Ideas that crash and fail don't add to the debt of the original language.
I hope the fork goes well and this proves a net gain for the original ecosystem.
D is a real anomaly to me because it should have had the same trajectory as Rust, it vastly improved upon other systems languages at conception, the authors evangelized it, including at FAANG, and yet, Rust seems to have gained traction everywhere D failed to do so. Even in places where C++ has historically been shunned, Rust has some traction (Linux Kernel). I now believe that language adoption is just a product of the right news cycles and timing, and perhaps hype over the creators or a certain feature. I am sad we got Rust and not D. D is so much easier to grok as a C++ person, and I think Rust is incredibly verbose looking.
I don't find it particularly surprising. D uses a garbage collector while C, C++ and Rust do not. D's GC can be disabled but that isn't that useful when most D code including the standard library until just a few years ago were not written with that in mind.
D is much more closely a competitor of C# than it is C++. D has a few nice features like advanced compile time programming but the actual nuts and bolts that Staff engineering management looks isn't really solid. D's GC is a design straight out of the 80's. Dmd has good compiler throughout but code quality isn't very good. Ldc is much better but compile times are much longer.
Adopting languages at FAANG beyond a single team just yolo deploying them to production requires integrating dozens of engineering systems for everything from post mortem debugging to live profiling to authentication systems. The cost to do this is in the order of tens of millions of dollars.
D just isn't suitable as a C or C++ replacement in the places that actually require it and the cost to enable it in large companies isn't worth it for the incremental improvement it does offer in some areas.
Rust has memory safety without GC, and a from-scratch language design. D is an evolutionary development of C++ (which is also gaining new features of its own) with little to recommend it besides. A comparison with Carbon and cppfront is also instructive, note that both of those have not added GC to the language.
Culture matters. "Culture eats strategy for breakfast". Rust has a safety culture. Yes it has a bunch of safety technology but the technology doesn't decide how things are used. It would be legal using the Rust compiler to implement the IndexMut trait on slices such that it just YOLOs like a C++ index. Rust doesn't do that, not because somehow the technology forbids it - it does not - but because culturally it's anathema to them.
When I heard about D it was often in combination with issues that seemed rather basic. Like multiple mutually exclusive runtime libraries that made D libraries incompatible with each other from the start, or hard version breaks that where trying to solve fundamental issues but also caused projects to lag behind for years. Have you seen how long the Python 2 to 3 migration took? The news cycles didn't do anything to fix that mess either.
I know that calling it "FreeD" is probably a bad idea but I would have thought it was real clever. I've toyed with the language before and it was always enjoyable, just lacked the library/compiler support that I need for the sorts of things I'd use D for so I've stuck with C, looking forward to trying again in a couple years if this sticks!
The person that wrote the post is Adam Ruppe. He's a very prolific D programmer, best known for these libraries https://github.com/adamdruppe/arsd and for publishing a book on the language.
It's too early to judge how much support there will be. I don't expect current users to split into camps though. My prediction is that the relationship will end up being similar to Ubuntu vs Debian. An example is string interpolation. Walter wants to stick to his own proposal, which nobody else likes, while Adam's already implemented his proposal in OpenD.
what D imo would benefit most of is a cohesive standard library that comes with batteries included and makes it easy to ship real world apps and services.
basically what Go did, having many standard protocol implementations within stdlib.
He pretty much derailed the D forum forking thread into remotely related tech discussion. This was weird to observe tbo, in the end my take is that he doesn't seem to bother much and would rather continue living in his version of the story.
X.Org. (if you know what X is, you are familiar with X.Org, which is a fork of XFree86)
Chromium is a fork of Webkit which is a fork of KHTML. If you use a web browser, that browser is either Firefox or a fork (of a fork) of KHTML. I don't know what percentage of Chromium/Webkit users have heard of KHTML, but I'd recon it's on the order of 1%.
mplayer used to be a very popular, very good media player, mostly for linux but it was cross platform. Development sort of died. These days its fork mpv is much more common.
There used to be many different forks of GCC. In 1997, all of these developers merged their forks together into the EGCS project. This project proved to be very active and very...good. It was so good that the FSF halted development on mainline GCC, forked EGCS into the new mainline GCC, and restructured the community built around the ideas of the EGCS community. If you use GCC, this is the version you use; forked from GCC into EGCS, forked from EGCS back into GCC.
MacOS' kernel is a fork of FreeBSD. Much of its userspace is a fork from ... somewhere. If you use MacOS it's forks all the way down.
Kindle is forked from Android and/or linux and/or... well it's complicated. Amazon forked a lot of stuff.
Much of the Android ecosystem has been forked. OpenSSL was forked into Tink, for instance. Again, complicated, lots of forks.
yt-dlp was forked from youtube-dl when ... the lawyers came.
[+] [-] jeffparsons|2 years ago|reply
[+] [-] tastyminerals2|2 years ago|reply
[+] [-] ktm5j|2 years ago|reply
[+] [-] pjmlp|2 years ago|reply
Almost everything I liked in D when Andrei Alexandrescu's book came out in 2010, have made its way to C#, Java, C++.
Yeah, maybe the implementation isn't as nice as in D, but that hardly matters when the implementation is available in some form, with much better tooling and library ecosystem.
Too many years lost chasing the golden feature that would bring people in, without stabilitizing those features.
Even Andrei is nowadays apparently mostly busy with C++ and CUDA than D.
And then there is the whole compile to native programming languages renaissance from the last decade, adding even more competition.
Which is a pity, as the community itself is full of great folks to talk with.
[+] [-] Shorel|2 years ago|reply
I am using Python every day. And there are many things from D which I miss. Not to mention the performance.
[+] [-] xpressvideoz|2 years ago|reply
[+] [-] fasterik|2 years ago|reply
[+] [-] bsdpufferfish|2 years ago|reply
[+] [-] chromatin|2 years ago|reply
While I wish Adam and the others success with OpenD, I hope they can take the opportunity to pick a more unique/memorable name.
[+] [-] djha-skin|2 years ago|reply
[+] [-] logicchains|2 years ago|reply
[+] [-] Starlevel004|2 years ago|reply
[+] [-] chalsprhebaodu|2 years ago|reply
FreeD
[+] [-] ReleaseCandidat|2 years ago|reply
[+] [-] jacquesm|2 years ago|reply
I'm sure that there are legitimate gripes and D's reliance on Walter as gatekeeper may be too strict for some but the way this fork has started out doesn't bode well for the long term. Forks succeed only if they are carried broadly, you'd need to more or less pull a majority of the folks in the D community along rather than just a handful of prolific but ultimately low in number individuals because there is a fair chance that both your fork will fail and that you further fragment the mindshare of the original to the point that it too looses any viability that it still had.
You also need to be able and willing to support it for decades.
[+] [-] apgwoz|2 years ago|reply
Personally, I think it’d have been more fun if they named it ‘Died’ — you get the benefits of sweet taglines “It never Died,” a statement about it being a fork, and the permission to take the language in new directions if that makes sense in the future. OpenD implies full compatibility, etc..
(I have no skin in this game, though. Good luck!)
[+] [-] xeeeeeeeeeeenu|2 years ago|reply
[+] [-] fsckboy|2 years ago|reply
sounds from this like the people forking basically want a different language, for which they're willing to make a number of breaking changes.
[+] [-] logicprog|2 years ago|reply
Honestly, I've always felt really confused about what D's vision is. I've tried reading some of the docs about certain language features like better see and safe mode and lifetimes and they've been grammatically just kind of hard to read and generally poorly explained, despite going into great detail on things, and I've never really been able to get a sense for a coherent design vision or purpose for the language. The author mentions that this has been a problem, but I don't feel their vision is really any clearer. Yes they have a few concrete midterm technical goals, which is great, but it isn't clear to me what those goals are in service of. Honestly, I'm a rust programmer, so you know what I do for Greenfield personal projects, but I'd rather just use OCaml, C++, or even C# if I had to pick something else.
[+] [-] neilv|2 years ago|reply
Most of the changing languages that come to mind, I realize, that they, too, had a big upset or oops related to governance.
I now think one of the key things to look for in a programming language is governance -- what they say about how they do it, what they actually do, how that's working out so far, and how you think that will work out in the future.
[+] [-] lifthrasiir|2 years ago|reply
[+] [-] bsdpufferfish|2 years ago|reply
[+] [-] flohofwoe|2 years ago|reply
IMHO that's the main reason why C became so popular, compilers are free to explore into different directions, language extensions that have proven their worth will eventually be picked up by other implementations, and sometimes even make it into the standard without being butchered too much by the committee agreement process.
[+] [-] rnd0|2 years ago|reply
[+] [-] JonChesterfield|2 years ago|reply
Language design is difficult. Features interact in complicated ways. Fixing mistakes is tricky - you break existing code.
Forking D sounds fine. It's easier to start with an implementation than to go from scratch. Ideas which work out well get to have a existence proof when proposing them to the original. Ideas that crash and fail don't add to the debt of the original language.
I hope the fork goes well and this proves a net gain for the original ecosystem.
[+] [-] softirq|2 years ago|reply
[+] [-] dequan|2 years ago|reply
D is much more closely a competitor of C# than it is C++. D has a few nice features like advanced compile time programming but the actual nuts and bolts that Staff engineering management looks isn't really solid. D's GC is a design straight out of the 80's. Dmd has good compiler throughout but code quality isn't very good. Ldc is much better but compile times are much longer.
Adopting languages at FAANG beyond a single team just yolo deploying them to production requires integrating dozens of engineering systems for everything from post mortem debugging to live profiling to authentication systems. The cost to do this is in the order of tens of millions of dollars.
D just isn't suitable as a C or C++ replacement in the places that actually require it and the cost to enable it in large companies isn't worth it for the incremental improvement it does offer in some areas.
[+] [-] zozbot234|2 years ago|reply
[+] [-] tialaramex|2 years ago|reply
[+] [-] josefx|2 years ago|reply
[+] [-] akvadrako|2 years ago|reply
D could have been something but most people avoided it because of the commercial nature, i.e. not being Free software.
[+] [-] kadoban|2 years ago|reply
[+] [-] thot_experiment|2 years ago|reply
[+] [-] systems|2 years ago|reply
D is a very small community , so this seem to be a big bet
[+] [-] bachmeier|2 years ago|reply
It's too early to judge how much support there will be. I don't expect current users to split into camps though. My prediction is that the relationship will end up being similar to Ubuntu vs Debian. An example is string interpolation. Walter wants to stick to his own proposal, which nobody else likes, while Adam's already implemented his proposal in OpenD.
[+] [-] p0nce|2 years ago|reply
[+] [-] yawniek|2 years ago|reply
[+] [-] speps|2 years ago|reply
[+] [-] justin66|2 years ago|reply
> Again, remember, I have other work and responsibilities, so I can't do a great deal of work myself, even if I wanted to.
[+] [-] tlivolsi|2 years ago|reply
[+] [-] tastyminerals2|2 years ago|reply
[+] [-] wussboy|2 years ago|reply
[+] [-] emrah|2 years ago|reply
[+] [-] nwallin|2 years ago|reply
Chromium is a fork of Webkit which is a fork of KHTML. If you use a web browser, that browser is either Firefox or a fork (of a fork) of KHTML. I don't know what percentage of Chromium/Webkit users have heard of KHTML, but I'd recon it's on the order of 1%.
mplayer used to be a very popular, very good media player, mostly for linux but it was cross platform. Development sort of died. These days its fork mpv is much more common.
There used to be many different forks of GCC. In 1997, all of these developers merged their forks together into the EGCS project. This project proved to be very active and very...good. It was so good that the FSF halted development on mainline GCC, forked EGCS into the new mainline GCC, and restructured the community built around the ideas of the EGCS community. If you use GCC, this is the version you use; forked from GCC into EGCS, forked from EGCS back into GCC.
MacOS' kernel is a fork of FreeBSD. Much of its userspace is a fork from ... somewhere. If you use MacOS it's forks all the way down.
Kindle is forked from Android and/or linux and/or... well it's complicated. Amazon forked a lot of stuff.
Much of the Android ecosystem has been forked. OpenSSL was forked into Tink, for instance. Again, complicated, lots of forks.
yt-dlp was forked from youtube-dl when ... the lawyers came.
Ubuntu is a fork of Debian.
[+] [-] coder543|2 years ago|reply
[+] [-] suchire|2 years ago|reply
[+] [-] sixthDot|2 years ago|reply
[+] [-] HKH2|2 years ago|reply
[+] [-] Alifatisk|2 years ago|reply