Thoughts on Backward Compatibility

[Carl Sturtivant]

On Monday, 19 February 2024 at 17:14:21 UTC, Dukc wrote:
> It revolves around the fact it's truly general purpose - 
> scripting, application development and systems programming all 
> equally supported. And also that the language doesn't impose 
> restrictions just for sake of some stylistic discipline.

+1

> If D ever were to "pick it's camp" and either force me to use 
> the GC and the standard runtime whether I want or not, or 
> alternatively ditch the GC it and impose RAII/ref counting 
> instead, that would drive me away.

To be clear, I am not suggesting that D should force using the 
GC. Quoting the article I mentioned 
(https://bitbashing.io/gc-for-systems-programmers.html):
>Many developers opposed to garbage collection are building 
>“soft” real-time systems. They want to go as fast as 
>possible—more FPS in my video game! Better compression in my 
>streaming codec! But they don’t have hard latency requirements. 
>Nothing will break and nobody will die if the system 
>occasionally takes an extra millisecond.
> [...]
>**Modern garbage collection offers optimizations that 
>alternatives can not.** A moving, generational GC periodically 
>recompacts the heap. This provides insane throughput, since 
>allocation is little more than a pointer bump! It also gives 
>sequential allocations great locality, helping cache performance.
> [...]
>I’m not suggesting that all software would benefit from garbage 
>collection. Some certainly won’t. But it’s almost 2024, and any 
>mention of GC—especially in my milieu of systems 
>programmers—still drowns in false dichotomies and FUD. *GC is 
>for dum dums, too lazy or incompetent to write an "obviously" 
>faster version in a language with manual memory management*.
>
>It’s just not true. It’s ideology. And I bought it for over a 
>decade until I joined a team that builds systems—systems people 
>bet their lives on—that provide sub-microsecond latency, using a 
>garbage-collected language that allocates on nearly every line. 
>It turns out modern GCs provide amazing throughput, and you 
>don’t need to throw that out for manual memory management just 
>because some of your system absolutely needs to run in n clock 
>cycles. (Those *specific parts* can be relegated to non-GC code, 
>or even hardware!)

What I *am* suggesting is that a modern GC for D would be a 
game-changer, with the default of using the GC being the best 
answer most of the time. People who didn't believe this could 
find it out experimentally.