On Tuesday, 19 January 2021 at 13:41:33 UTC, ddcovery wrote:
That you want GC to work efficiently seems great to me... but at least we agree that D memory management is (and must be) GC based (so I really don't understand your somewhat over-acted answer... maybe I need to read all the threads to understand your discomfort. In any case, accept my forgiveness if I have been able to bother you).
I think we need to understand the landscape around us. What was possible development directions for D 2-5 years ago are now less viable, because it is now a game of (forever) catching up to the other ones (C++/Rust) rather than being something different. 5 years ago I would argued more for competing with C++/Rust head-to-head. I think that train has left the station. D is on a different track now.
So the possible viable directions has shrunk to improving the GC (by some minor language adjustments), switching to ARC or some other paradigm that give roughly the same programming experience as D users are accustomed to.
Regarding the experience, do we really have to go into that? In this forum there are more or less many people with university level and between 10 and 30 years of experience ...
Yes, but would most of those have chosen D over Rust, Zig, Nim, C++20 today? We cannot know for sure, but there is clearly a significant uptake for competing languages that did not exist 10 years ago.
So the "recruiting pool" is shrinking, that means losses (people leaving) cost even more today than 10 years ago...
So yes, we should absolutely listen to concerns from experienced developers with Comp.Sci. background if they chose to share them here in the forums. Tooling is a much bigger issue, but language/runtime adjustments are possible if we are willing to take some inconvenience in transition (some breakage).
In my case, for example, I have not worked manually with memory for decades (the 90s are a long way off, and my years with
Yes, I don't think most people want to work manually with memory, which is why mix-and-match is not sitting well. People who really want to do fully manual stick to C (they don't even want C++, right?).
Anyway, the more cores CPUs get, the more unacceptable blocking threads gets.
But I also suspect thread-pooling will eventually become the only reasonable option as one has to support CPUs with 2-30 cores... difficult to do that with a threading model. So, there are many... issues. Maybe threading is not the best model... Not sure.
