The easiest way to compete with Rust and cure D's GC reputation: switch to ARC.

[WraithGlade]

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](https://en.wikipedia.org/wiki/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!