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