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...
