←back to thread

271 points mithcs | 2 comments | | HN request time: 0s | source
Show context
cachius ◴[] No.45953162[source]
A recent superpower was added by Fil aka the pizlonator who made C more Fil-C with FUGC, a garbage collector with minimal adjustments to existing code, turning it into a memory safe implementation of the C and C++ programming languages you already know and love.

https://news.ycombinator.com/item?id=45133938

https://fil-c.org/

replies(3): >>45953284 #>>45953390 #>>45954377 #
762236 ◴[] No.45953390[source]
Why would I want to run a garbage collector and deal with it's performance penalties?
replies(4): >>45953453 #>>45953598 #>>45953991 #>>45961132 #
jerf ◴[] No.45953598[source]
Because about 99% of the time the garbage collect is a negligible portion of your runtime at the benefit of a huge dollop of safety.

People really need to stop acting like a garbage collector is some sort of cosmic horror that automatically takes you back to 1980s performance or something. The cases where they are unsuitable are a minority, and a rather small one at that. If you happen to live in that minority, great, but it'd be helpful if those of you in that minority would speak as if you are in the small minority and not propagate the crazy idea that garbage collection comes with massive "performance penalties" unconditionally. They come with conditions, and rather tight conditions nowadays.

replies(6): >>45953687 #>>45953716 #>>45953741 #>>45953976 #>>45959310 #>>45960864 #
hypeatei ◴[] No.45953687[source]
I think these threads attract people that write code for performance-critical use cases which explains the "cosmic horror" over pretty benign things. I agree though: most programs aren't going to be brought to their knees over some GC sweeps every so often.
replies(2): >>45954755 #>>45956652 #
KerrAvon ◴[] No.45954755[source]
Outside of hobbyist things, performance-critical code is the only responsible use case for a non-memory safe language like C in 2025, so of course it does. (Even that window is rapidly closing, though; languages like Rust and Swift can be better than C for perf-critical things because of the immutability guarantees.)
replies(3): >>45956586 #>>45956777 #>>45958223 #
1. sramsay ◴[] No.45956777{5}[source]
I keep hearing this, but I fail to see why "the massive, well-maintained set of critical libraries upon which UNIX is based" is not a good reason to use C in 2025.

I have never seen a language with a better ffi into C than C.

replies(1): >>45960432 #
2. lmm ◴[] No.45960432[source]
> the massive, well-maintained set of critical libraries upon which UNIX is based

What massive, maintained set is that? Base Unix is tiny, and any serious programming ecosystem has good alternatives for all of it.