I have a plan.. I really DO

[Ecstatic Coder]

On Wednesday, 4 July 2018 at 18:05:15 UTC, wjoe wrote:
> On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder wrote:
>> But indeed, being able use D in a GC-free environment (like 
>> C++ and Rust do) would be something many people may NEED, for 
>> instance to be able to EASILY use D for soft-realtime 
>> applications like games.
>
> This has to be the no. 1 excuse.
>
>
> Why is C++ the language of choice currently? My bet is 
> productivity and economic concerns. Amongst other things the 
> productivity gain from resource management via constructor and 
> destructor. Which solves like 75% of the headaches of manual 
> resource management and goto nightmares.
>
> Back in the day when C was used to make games, the excuse not 
> to use C++ was vtable, exception and RTTI overhead. Now it's 
> called the bare metal best performance language which 
> everything and their grandma is measured against. This C++ 
> overhead didn't make C any slower or C++ any faster than C but 
> it made C++ superior in productivity.
>
> This was around 2002/03, and C++, at the time, some 23+ years 
> old.
>
> Games have been made with GC'd languages, 3D games, even. And 
> successfully, too.
> Minecraft, a very successful one, comes to mind, which is or at 
> least was made in Java.
> Plenty of games are made in C#, too.
>
> My bet, again, would be productivity and economic concerns. The 
> countless hours wasted on debugging memory leaks and cyclic 
> dependencies are better spent making the actual game/software.
> And smart pointers introduce overhead of their own which makes 
> them inferior to C's bare metal raw pointer performance - or 
> GC'd pointers for that matter. The culprit being the collection 
> cycle.
>
> The best thing about this whole argument, however, is the claim 
> for GC no can do and with the next breath they pull LUA into 
> their games. A scripting language that brings a VM, GC and 
> extraordinarily inflated loading times when the scripts are 
> compiled to byte code at the end user's PC which make C64 
> loading times shine.
> The reasoning probably being productivity again and C++'s lunch 
> break compile times.
>
> Using the D compiler as a library, instead of LUA, D code could 
> be used for 'scripting', as well, and compiled to native 
> machine code. In a snap.
>
> I have no metrics between any AAA game engine and their port to 
> D but I do know that I wrote a sound/music player library in 
> Java, which folks like you claim impossible because GC, never 
> bothered with GC and had no performance issues whatsoever - and 
> I don't expect any porting it to D.
>
> And there is EASTL. A STL made by Electronic Arts. Because the 
> standard implementation shipped with the compiler is too slow ? 
> Even though written by C++ wizards ?
>
>
> Slow code is slow and allocating memory in a tight loop is a 
> huge performance killer - regardless of language.
>
> Also, why do you feel like a GC is inacceptable for games but 
> doesn't matter for your file handling program? Handling dozens, 
> maybe thousands, of files sounds like an awful lot of memory 
> management involved and whether a e.g. grep takes 15 seconds to 
> do it's job or under 1 matters not?
>
> Nothing forces anyone to use the GC, memory can be managed 
> manually via malloc/free and you get to do it with scope 
> statements/nested functions which makes it nicer than in C. You 
> could also implement shared/weak ptr stuff in D - warts and all.
> If you need a GC free standard library, I believe there is an 
> ongoing effort -or several- at code.dlang.org and probably 
> other places.
>
>
> You said do this and that, GC, etc. to motivate C++ folks to 
> come to D. I say it's an excuse not to use D and no matter the 
> effort of advertising, a GC free phobos, etc. on part of the 
> D-Lang Foundation and contributors would make these folks 
> switch. They would simply find a different excuse.
>
> And where's the usefulness of toy examples like 2 line web 
> servers which essentially do nothing?
> And how is that helping with getting attention from the game 
> devs ?
> Putting on the front page a 12 line maze game which can be 
> imported from the standard library? Not using the GC?

First, to be clear, I mainly use D as a scripting language for 
file processing, and for this use case, having a GC is a blessing.

You say that garbage collection is not a real problem for game 
development.

Maybe, but that's not my experience. For instance, have you read 
Unity's own official recommandations on how to overcome this 
problem ?

And obviously, Tibur, a highly skilled D game engine developer, 
is not a big fan of D's non incremental garbage collector, from 
the number of @nogc he has put in his Dlib container code.

Maybe you disagree with us because you are a professional game 
developer who has already released a successful commercial game 
in D without caring for the garbage collection. If it's the case, 
then nice, I'd be happy to have it wrong on this :)

And about developing video games in C++, actually most studios 
use orthodox C++. This means no exceptions, no RTTI, few virtual 
methods, fast lightweight smart pointers and collections, etc.

Of course it's perfectly your right to develop your games without 
caring for all these performance "details". But other people do.

And about the scripting language, it's not my fault if some game 
engine developers don't care for the performance or GC issues 
when adding a scripting language to their game engine.

But obviously, some of us (including me) care for that when 
implementing or using a scripting language.

So, as I said, those who use C++ or Rust because D's GC is a 
problem for them, won't probably use D in its current state.

But I'm personally convinced that D could be much more successful 
if it was enhanced to be marketed as a true Go-like language than 
if it was enhanced to be marketed as a true C++-like language, 
for the reasons I've already explained, so I don't think that D's 
GC is really a problem from that point of view...