←back to thread

Giving C a superpower: custom header file (safe_c.h)

(hwisnu.bearblog.dev)
271 points mithcs | 2 comments | 17 Nov 25 10:40 UTC | HN request time: 0.412s | source
Show context
cachius ◴[17 Nov 25 12:56 UTC] 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 ◴[17 Nov 25 13:30 UTC] 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 #
sesm ◴[17 Nov 25 14:42 UTC] No.45953991[source]▶
IDK about Fil-C, but in Java garbage collector actually speeds up memory management compared to C++ if you measure the throughput. The cost of this is increased worst-case latency.

A CLI tool (which most POSIX tools are) would pick throughput over latency any time.

replies(5): >>45954231 #>>45954275 #>>45954762 #>>45954883 #>>45958686 #
1. zozbot234 ◴[17 Nov 25 15:06 UTC] No.45954231[source]▶
You also pay for the increased throughput with significant memory overhead, in addition to worst-case latency.
replies(1): >>45954698 #
2. KerrAvon ◴[17 Nov 25 15:54 UTC] No.45954698[source]▶
This. The memory overhead kills you in large systems/OS-level GC. Reducing the working set size really matters in a complex system to keep things performant, and GC vastly expands the working set.

In the best cases, you’re losing a huge amount of performance vs. an equivalent non-GC system. In the worst, it affects interactive UI performance with multi-second stalls (a suitably modern GC shouldn’t do this, though).