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.
They didn't say it would be different now, they're just reminding people that Walter is here on HN so to try to be respectful and realize that he's a human being too. Unlike most here, he's attached his real identity to this project, so drive by anonymous pot shots would be inappropriate.
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.
D's ownership/borrowing system does not require any language changes. It is opt-in at the function level to preserve compatibility with existing code. It does not break backward compatibility. It works as a prototype now, you can try it out.
It does decrease compilation speed, because O/B requires data flow analysis. However, this is speed slowdown only happens for the functions marked as being O/B functions.
Given that Sean Baxter already has lifetimes in Circle that work very similarly to Rust's, I'm skeptical that the very similar D language wouldn't be able to express the same thing.
Not someone else, but many others. I value projects governed by multiple people because one person cannot be an expert in every field, even though that person is smarter than most people.
Given one of their stated goals is "Embracing the GC and improving upon it, disregarding betterC and nogc in the process", it seems like their goal is explicitly to move it away from being a system programming 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.
> 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++
Yeah, for a long time the language was marketed as a better C++. That was wrong for two reasons. First, it's a C++ replacement, but it's not C++, as many C++ developers learned in frustration. Second, it's a lot more than a C++ replacement. It works for scripts, as a general programming language, and especially for C interop (ImportC, BetterC, etc.)
One of the goals of the fork is to stop apologizing for the GC. You still have reference counting, unique pointers, and whatever in the standard library. I'm sure if someone wants to contribute functions that avoid the GC, they'll be accepted. What you're not likely to see with the fork is Adam writing new functions for the standard library that go to great lengths to avoid the GC. He believes fear of the GC is overblown.
Right, but even if this was always the most consistent/accurate direction for D, so it isn't actually a change in direction technically speaking, that still leaves the main point of what I wrote unanswered — how can its new direction find it a niche when it has to compete in the "GC'd but very fast C++ successor language" space with C# and Java?
Also, this idea that fear of the GC is overblown — I buy that for servers and applications and the like for the most part (although I think our obsession with using heavier and heavier runtimes and frameworks to ease development at the cost of efficiency is unsustainable in the long term and has contributed significantly to the bloat of modern systems), but for real-time work, or embedded systems, or low level programming that needs to implement the sort of things a GC or runtime relies on, which are the only things I think most people claim GCs aren't good for, I really don't buy the argument that GCs don't matter. Yes you can do such things with languages that have them, especially if you have cutting edge GCs like Java's ZGC or turn your runtime into bare metal hardware drivers like Miranda did with OCaml, but oftentimes that's just harder to reason about and control, more work, and has costs (like ZGC needing 2x the memory and roping all pointer accesses into doing GC work to amortize processing costs), so it's like that article about using C# to do a <2KB game — why not just use things more well suited for that. This is a common sentiment I've seen in the D community though, so let me ask directly: is this argument a response to people who are claiming not to want a GC for low level / systems programming, in which case I don't think it's very reasonable, or is this a response to people who balk at GC for server and application stuff, in which case I'm not sure anyone disagrees? Or is there a third option I'm missing?
Readit News
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 am using Python every day. And there are many things from D which I miss. Not to mention the performance.
It does decrease compilation speed, because O/B requires data flow analysis. However, this is speed slowdown only happens for the functions marked as being O/B functions.
While I wish Adam and the others success with OpenD, I hope they can take the opportunity to pick a more unique/memorable name.
Oh, didn't know that they are working on this.
https://github.com/coq/ceps/blob/coq-roadmap/text/069-coq-ro... and, of course, https://news.ycombinator.com/item?id=38779480
069-coq-roadmap.md? Oh, you!
So now we've got Rocq and Roc https://www.roc-lang.org/
Deleted Comment
And no, I didn't miss the joke :)
FreeD
Too bad it's not focused on a windowing system, they could go with Dfenestration :)
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..
(I have no skin in this game, though. Good luck!)
sounds from this like the people forking basically want a different language, for which they're willing to make a number of breaking changes.
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.
Yeah, for a long time the language was marketed as a better C++. That was wrong for two reasons. First, it's a C++ replacement, but it's not C++, as many C++ developers learned in frustration. Second, it's a lot more than a C++ replacement. It works for scripts, as a general programming language, and especially for C interop (ImportC, BetterC, etc.)
One of the goals of the fork is to stop apologizing for the GC. You still have reference counting, unique pointers, and whatever in the standard library. I'm sure if someone wants to contribute functions that avoid the GC, they'll be accepted. What you're not likely to see with the fork is Adam writing new functions for the standard library that go to great lengths to avoid the GC. He believes fear of the GC is overblown.
Also, this idea that fear of the GC is overblown — I buy that for servers and applications and the like for the most part (although I think our obsession with using heavier and heavier runtimes and frameworks to ease development at the cost of efficiency is unsustainable in the long term and has contributed significantly to the bloat of modern systems), but for real-time work, or embedded systems, or low level programming that needs to implement the sort of things a GC or runtime relies on, which are the only things I think most people claim GCs aren't good for, I really don't buy the argument that GCs don't matter. Yes you can do such things with languages that have them, especially if you have cutting edge GCs like Java's ZGC or turn your runtime into bare metal hardware drivers like Miranda did with OCaml, but oftentimes that's just harder to reason about and control, more work, and has costs (like ZGC needing 2x the memory and roping all pointer accesses into doing GC work to amortize processing costs), so it's like that article about using C# to do a <2KB game — why not just use things more well suited for that. This is a common sentiment I've seen in the D community though, so let me ask directly: is this argument a response to people who are claiming not to want a GC for low level / systems programming, in which case I don't think it's very reasonable, or is this a response to people who balk at GC for server and application stuff, in which case I'm not sure anyone disagrees? Or is there a third option I'm missing?