Garbage Collection and gamedev - tl;dr Yes we want it, so let's solve it

[Ola Fosheim Grostad]

On Friday, 27 November 2020 at 20:41:33 UTC, Guillaume Piolat 
wrote:
> really), I'm saying that the traits that make people switch to 
> a new language are desirable properties of the _library they 
> want to use_, more than the language.

Yes, or the service it runs on. Which is why I think D ought to 
encourage separating  framework from app. Let the framework do 
the multithreading and let the app author write simple single 
threaded tasks. So basically the framework deals with shared and 
app authors can mostly ignore that... That would be a good reason 
to have single threaded GC, which also would enable fast 100% 
precise collection and correct destruction and RAII. I think we 
could even get the destructor order right.

However, ARC is more generally useful... For me.

> Soft disagree. This sounds to me like a high-debt solution.
> If you make a game engine for example, cost of making N games 
> is O(N), but cost of having a new platform is O(1). If added 
> value flow to the game engine properly, you _will_ end up 
> having support for all platforms needed.

Godot does not even support Metal or Direct X?

For web I actually only want really efficient debuggable wasm. 
The browser is the framework and apps should load and run in 1 
second. Flutter is a bit bloated, but probably less bloated than 
unity/godot... And better UI support... But generally speaking... 
Frameworks are more a hindrance for what I want to achieve.

Anyway, my point was more: if your goal is to build a framework, 
then you would not do it to promote a specific language. So I 
dont think the D community can decide this to be a focus.

We can only focus on the enabling language features, getting rid 
of the irritatiting pain points.

(Why is typing on ipads so... Nggh?)