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