I have a plan.. I really DO

[aberba]

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.
+1
>
>>
>> Slow code is slow and allocating memory in a tight loop is a 
>> huge performance killer - regardless of language.
+1

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

https://dlang.org/blog/2016/09/16/project-highlight-timur-gafarov/

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.