How usable is the D language without a garbage collector?

[welkam]

On Friday, 15 July 2022 at 09:27:51 UTC, LinguisticMystic wrote:
> D seems to be a good one as it ticks all the boxes of C++ while 
> fixing most (all?) of its flaws.

It was said before but I will repeat it. Try not to view D as C++ 
with its flaws fixed but as C with features added to it. If you 
would to expect D to behave like C++ you will get frustrated as D 
doesnt behave like C++ in some cases.

> My necessary requirement is that the runtime should not 
> include<...>

Im not surprised you wrote that. Zero cost abstractions and 
minimal runtime are like gospel in C++ circles. Its not 1990 
anymore and in modern times these things almost dont matter when 
compared to memory copying, allocations and cpu cache usage. If 
you want your code to go fast pay attention to memory. One time a 
D project had a crown of being the fastest json parser in the 
world. It achieved that by avoiding making temporary heap 
allocations.
https://forum.dlang.org/thread/20151014090114.60780ad6@marco-toshiba

> Does the [@nogc] switch apply globally, so that the compiled 
> binary is free from GC code?

GC does not run periodically like a cron job. It can only runs 
when you are making an allocation. @nogc applies to a scope and 
compiler makes sure that no GC allocations occur in that scope. 
If you put @nogc at main() then your program cant allocate GC 
memory. If you never allocate from GC then its not going to be 
initialized. If GC is not initialized at all then its never used 
and code that's never used is not linked in final binary.

> Is it better for me to look elsewhere if I don't want GC?

I dont think so. While D usage without GC is not streamlined I 
believe its still a better  package as a whole compared to 
alternatives especially if you write green field projects.

If you want to write games in D you might be interested in this 
GDC talk
https://gdcvault.com/play/1023843/D-Using-an-Emerging-Language