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

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.

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

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

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.

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

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

GC in not a performance bottle neck if you truly know what you're doing.

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.

Reply via email to