←back to thread

Fil's Unbelievable Garbage Collector

(fil-c.org)
597 points pizlonator | 1 comments | 05 Sep 25 00:55 UTC | HN request time: 0.215s | source
Show context
illuminator83 ◴[05 Sep 25 11:16 UTC] No.45137283[source]▶
IMHO Garbage collection is and always was an evolutionary dead end. No matter how nice you make it, it feels wrong to make a mess and have some else clean it up inefficiently at some point later.

And because of that it always involves some sort of hidden runtime cost which might bite you eventually and makes it unusable for many tasks.

I'd rather have my resource management verified at compile time and with no runtime overhead. That this is possible is proven by multiple languages now.

That being said, I can imagine some C programs for which using Fil-C is an acceptable trade-off because they just won't be rewritten in language that is safer anytime soon.

replies(7): >>45137347 #>>45137597 #>>45137631 #>>45138183 #>>45138524 #>>45138652 #>>45139079 #
1. titzer ◴[05 Sep 25 13:56 UTC] No.45138652[source]▶
The topic has been debated for decades. It's your opinion but it's pretty reductionist and basically religious one at this point. All memory management has costs, both at compile time, run time, and cognitive overhead. You can move costs around, reduce them, and avoid some, but you'll never get away from it.

> it feels wrong to make a mess and have some else clean it up inefficiently at some point later.

Yet no one argues for manual register allocation anymore and will gleefully use dozens or even hundreds of locals and then thousands of functions, just trusting the compiler to sort it all out.

We make progress by making the machines implement our nice abstractions.