←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: 0s | 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. dan-robertson ◴[05 Sep 25 12:13 UTC] No.45137631[source]▶
Garbage collection performance lies along a memory-overhead vs time-overhead curve which can be tuned. Manual memory management sits at one end (minimal memory overhead) but is often slower than garbage collection if you are willing to accept some space overhead. Observe that the most performance sensitive programs worry a lot about allocation whether or not they use garbage collection.