Permalink
Reply
Technically, I actually mentioned this idea twice before in my comments elsewhere tangentially, in a more muted and more easily missed form, but I think it is one of the most compelling potential ways to make D (and indeed any/all other aspiring easy to use and expressive systems programming languages) compete better and to be better engineered for the kinds of niches people would consider D for.
In particular, it seems to me that by far the easiest way to cure D of its GC-dependent reputation (which is one of the biggest reasons why people avoid using D) is to switch the whole standard language and library to use ARC based memory management instead. This would result in memory and performance characteristics that are on par with well-made modern C++ code and yet still just as easy (or at least almost as easy) to manage as GC-based code.
This would require far less pervasive and tedious change to D than attempting to compete directly with Rust (or similar models) would and yet would yield most of the same benefit.
Basically, ARC (automatic reference counting) means deterministic reference counting that is strictly based on scope-based destructors being automatically called at all exit points while simultaneously ensuring that the memory allocation and deallocation scheme always takes the same amount of time and is as predictable as possible (within the constraints of modern hardware and operating systems, of course) such as by using a pool-like system (i.e. homogeneously allocated into separate memory structures per type size) or whatever else works.
The problem with GC in terms of real applications (not to be confused with people just parroting "GC is bad" on the internet without actually understanding it) has never really been the (perhaps higher than GC in total aggregate) computational overhead of it typically (except in very constrained contexts like some embedded systems, but then you'd be doing things manually probably anyway). Rather, the real problem with GC has always been its unpredictability and indeterminable execution time.
Having memory collection run at some unknown time in the future and with an unknown duration is a recipe for rendering any language or ecosystem that uses that GC unusable for hard realtime applications such as safety critical medical devices (where even a slight pause could cause an incorrect cut during surgery, etc) or video games that want/need to reduce unpredictable stuttering (such as to reduce the chance of epileptic seizures induced by frame stuttering or just to make a more pleasant experience). D's standard library and ecosystem being based on GC infectiously causes most of that ecosystem to thus be unusable.
If ARC is implemented seamlessly enough though then downstream code could be mostly uneffected. The API could be kept the same and GC calls could spit out no-op warnings.
At the same time, changing the D website to advertise that D has the same performance characteristics as smart object based modern C++ code and stopping advertising the language as being garbage collected could potentially bring many users back that have previously eliminated the language from consideration due to the presence of the GC.
D's most similarly capable competitor Nim has already implemented this via its "ARC and ORC" system. Nim defaults to ORC, which is only partially deterministic for the sake of cycle elimination, but it can easily switch to ARC on command and the point still stands.
Personally I don't much care about cycles since they can be manually engineered around on a case by case basis and true determinism is a worth-while cost for that I think.
More broadly, and as I mentioned in my comments elsewhere, it surprises me that more languages haven't realized that this middle road exists and is potentially the most effective overall "best of both worlds" for both ease and memory safety.
Combining this switching to ARC with ensuring D's real world library ecosystem is actually usable and proven with examples of full scale complete software seems like the best thing D could do to regain relevance and credibility in the broader programming world.
Unrelatedly and briefly, regarding my own D language status, as of reading the very uninspiring and rhetorically disingenuous "it's just a tool" and "any moral objection regarding basic human rights is just politics" response to my concerns regarding the D team's stance on automated plagiarism and digital personhood violation, I will most likely be switching to another language, community, and ecosystem that seems less ideologically and morally risky (not Nim though, by the way, since they have sadly embraced such unconscionable "tools" even more enthusiastically). Of course, such immorality has been engineered to be "everywhere" now, seeing as the companies behind it have billions riding on it (etc), but there are still degrees of its prevalence and communities where it has less reach and less influence/control and I still am bound to my moral duty to act on that. I will check back later though, to see if things change (i.e. both regarding moral backbone and the D language and ecosystem itself). In any case, I may pop by this thread though again, or not, we'll see. I still think this (ARC) is a critical idea and so wanted to mention it for the greater good as a tentative pseudo-"parting" gift. Let's see if you're capable of change, basically, and likewise (to be fair) to myself (especially regarding my admittedly very bad language dilettante (un)productivity habits and such). In any case, have a great day/night/week everyone!
