Would you pay for GC?

[Ola Fosheim Grøstad]

On Tuesday, 25 January 2022 at 12:29:46 UTC, Paulo Pinto wrote:
>> For a language like D you could have ARC + borrow checker + 
>> the ability to constrain ARC-pointers (to get a unique_ptr) 
>> for shared objects and something GC-like for objects local to 
>> actors/tasks.
>
> In theory yes, in practice someone has to put down the money to 
> make it happen and ensure that the performance gains are worth 
> the money spent into it.

Actually, all it takes is for the core team to make it a 
priority. The existing GC can be taken as a starting point for 
local GCs, and you don't have to start with ARC, you can just 
start with well designed RC as a foundation to evolve from.

What is needed, to get this ball rolling as an open source 
project, is to focus on making the compiler more modular, 
especially the backend-interface.

So, I don't think this is a strict money issue.

Leadership needs to:

1. provide a the clean compiler architecture that allows adding 
additional static analysis

2. pick a memory management "coordination" design that can evolve 
in a open-source friendly manner (e.g. a protocol for purging 
unused/cached resources)

Only doable if leadership makes it a priority, as creating a 
better compiler architecture based on DMD is out of scope for 
individual contributors.

Without making memory management a priority, as a strategy, 
nothing will happen. And the reason for this is that good modern 
memory management requires solid static analysis and that is hard 
to add, for outsiders, to the current compiler architecture.

It is also clear that maintaining a separate branch of the 
compiler over time is not productive (given how D evolves, e.g. 
the sudden addition of import-C). It would be more satisfying to 
just create your own language then… *Which many D users seem to 
do!!!*

Given that last fact it becomes clear that this is not a money 
issue. People apparently find creating compiler tech enjoyable, 
if they have a good starting point to evolve from.

I don't think the D foundation necessarily has to provide a 
memory management solution that fits system level programming, 
but if it wants this to work as an well functioning open source 
project then the foundation must make sure that the core compiler 
infrastructure has well defined interfaces, and follows an open 
design philosophy, so that people can evolve solutions that fits 
their concrete projects and interests.

(Java had an advantage in having a well defined VM/IR that made 
it easy to build on for outsiders.)