Tasks, actors and garbage collection

Paulo Pinto pjmlp at progtools.org
Wed Apr 28 08:30:53 UTC 2021


On Tuesday, 27 April 2021 at 14:59:22 UTC, russhy wrote:
> On Tuesday, 27 April 2021 at 13:29:43 UTC, evilrat wrote:
>> On Tuesday, 27 April 2021 at 12:01:33 UTC, russhy wrote:
>>> And at least with Unreal, since it is using C++, you are not 
>>> forced to stick with the GC all the time
>>>
>>> With unity, they had to come up with a special language to 
>>> workaround the GC/JIT issues, and if you stick to regular C#, 
>>> you are forced to stick with the GC no matter what
>>
>> They don't. HPC# is a subset of C# without objects (no 
>> references).
>>
>>>
>>> So yes i want D to be as pragmatic as C++
>>>
>>>
>>> You guys want D to be as closed minded as C#, we all know 
>>> where that leads
>>>
>>
>> If it leads to be #1 platform for cross platform development 
>> that I'd call it success.
>>
>>
>> Oof. People who make games with Java can has malloc buffers 
>> via C bridge(libgdx if you want example), C# can even call C 
>> almost directly, that also opens the door to malloc and other 
>> allocators, moreover it is even has pointers right in the 
>> language (in unsafe code).
>>
>> And just to be clear, object pools is the GC managed memory, 
>> this is simply an optimization technique and not GC avoidance, 
>> the memory is still under GC control, it's still will be 
>> collected by GC at some point, it is just delayed to some 
>> moment in time in future.
>>
>> I don't get it, in D you have basically SINGLE scenario when 
>> GC actually runs - memory allocation using GC.
>> It just sits there, takes up just a bit of memory, but it 
>> doesn't waste your precious CPU ticks, it doesn't sucks power.
>> And the most important thing - you are free to manage the 
>> memory what ever way you want!
>> D even gives you the tools(-vgc flag) to know where exactly GC 
>> allocation can happen so you could optimize away that so much 
>> hated GC to zero.
>> All this available right now without changing the language and 
>> waiting for implementation.
>> So what's the problem with you?
>
> libgdx also is a pain in the ass to work with because you have 
> to constantly fight with java and the GC, they had to rewrite 
> all the data structures (collections etc because they allocate 
> on foreach)
>
> that is why libgdx is dead, java is not suitable for gamedev

LibGDX is pretty much alive, https://libgdx.com, I guess you keep 
referring to the old site.

Yes it probably has been shadowed by the facts that the original 
author kind of left the project after being burned with the 
Xamarin acquisition and shutdown from the original RoboVM project.

And the tiny detail that nowadays Unreal and Unity are mostly 
free beer for indies, alongside their GC implementations, 
graphical tools, the preferred teaching tool at game universities 
around the globe, with first party support from Microsoft, Apple, 
Google, Sony and Nintendo on their OS, VR/AR and gaming platforms.

As for Verona, it is Microsoft Research language and it is mostly 
paperware in 2021, did you forgot to read the link?

> This project is at a very early stage, parts of the type 
> checker are still to be implemented, and there are very few 
> language features implemented yet. This will change, but will 
> take time.



More information about the Digitalmars-d mailing list