On Wednesday, 4 July 2018 at 19:29:55 UTC, Ecstatic Coder wrote:
On Wednesday, 4 July 2018 at 18:05:15 UTC, wjoe wrote:
On Wednesday, 4 July 2018 at 08:50:57 UTC, Ecstatic Coder
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.
Games have been made with GC'd languages, 3D games, even. And
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.
Slow code is slow and allocating memory in a tight loop is a
huge performance killer - regardless of language.
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
That's what Timur said.
If you need a GC free standard library, I believe there is an
ongoing effort -or several- at code.dlang.org and probably
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.
You say that garbage collection is not a real problem for game
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.
He has written no-GC libs for sure but he said in a blog post
about his projects that he has no problem with GC. As long as you
do not use it in critical areas.
Modern D is a very attractive choice as a language for game
development. Even the garbage collector is not a problem,
because you can use object pools, custom allocators, or simply
malloc and free. The key point is to know when the GC is
invoked and try to avoid those cases in performance critical
code. Personally, I prefer using malloc so that I can free the
memory when I want, since delete has been deprecated and
destroy just releases all the references to an object instance
without actually deleting it. Using manual memory management
imposes some restrictions on the code–for example, you can’t
use closures or D’s built-in containers–but that, again, is not
a big problem. A large effort is currently underway to lessen
GC usage in dlib, so that you can use it to write fully
unmanaged applications with ease. It has GC-free containers,
file I/O streams, image decoders, and so on.
Remember he's into real-time stuff.
As an indie game developer with a strong bias toward graphics
engines and rendering tech, I always try to keep track of
modern compiled languages effective enough for writing
real-time stuff. The most obvious choice in this field is C++,
and I actually used it for several years until I found D in
2010. I immediately fell in love with the language’s clean,
beautiful syntax, its powerful template system, the numerous
built-in features absent in C++, and the rich and easy to use
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 :)
Read the blog post, you're wrong.
Of course it's perfectly your right to develop your games
without caring for all these performance "details". But other
GC in not a performance bottle neck if you truly know what you're
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.
If D had X people. Not customers.