On Tuesday, 6 May 2014 at 12:21:55 UTC, Paulo Pinto wrote:
As for the gaming world, I don't really have the required experience to talk much about it. Just doing the heads up that D GC != GC that many of us use.
I very much appreciate the links you provide about different GC solutions, and GC can be appropriate for real time situations where you don't want to maximize resource utilization or where you have predictable downtime to collect.
However the approach taken by appliances (where the application reliability is more important than getting the highest possible execution speed) or business solutions such as Azul Zing (where scalability is more important than hardware cost) is not really suitable for system level programming. It is suitable for a wide range of applications, that is true.
You can have GC with predictable destructors, but you have to design the language and runtime around it. You can have real time GC, but you need a dedicated GC and structure your program to realize the potential.
I think the only realistic road for D is to imposing/infer constraints that makes certain that execution paths is compatible with desirable runtime properties and available runtime support for that specific thread. There is no silver bullet, but the implementation driven design that D seems to be undergoing is affecting the resulting language/run-time design in a bad way, IMO.
