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?
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.