←back to thread

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

(hwisnu.bearblog.dev)
271 points mithcs | 6 comments | 17 Nov 25 10:40 UTC | HN request time: 0s | source | bottom
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 #
jerf ◴[17 Nov 25 13:59 UTC] 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 #
Phil_Latio ◴[17 Nov 25 14:17 UTC] No.45953741{3}[source]▶
> Because about 99% of the time the garbage collect is a negligible portion of your runtime

In a system programming language?

replies(3): >>45953871 #>>45953930 #>>45955348 #
pjmlp ◴[17 Nov 25 14:30 UTC] No.45953871{4}[source]▶
Yes, plenty have been done already so since Lisp Machines, Smalltalk, Interlisp-D, Cedar, Oberon, Sing#, Modula-2+, Modula-3, D, Swift,....

It is a matter to have an open mindset.

Eventually system languages with manual memory management will be done history in agentic driven OSes.

replies(2): >>45954791 #>>45960404 #
1. KerrAvon ◴[17 Nov 25 16:01 UTC] No.45954791{5}[source]▶
Swift, by design, does not have GC.
replies(2): >>45955042 #>>45955223 #
2. pebal ◴[17 Nov 25 16:21 UTC] No.45955042[source]▶
RC is a GC method and the least efficient one.
replies(1): >>45958203 #
3. pjmlp ◴[17 Nov 25 16:36 UTC] No.45955223[source]▶
Chapter 5,

https://gchandbook.org/contents.html

It would help if all naysayers had their CS skills up to date.

4. winrid ◴[17 Nov 25 20:58 UTC] No.45958203[source]▶
It's the most predictable and has much less overhead than a moving collector.
replies(1): >>45958511 #
5. pjmlp ◴[17 Nov 25 21:25 UTC] No.45958511{3}[source]▶
Only when we forget about the impact of cycle collections, or domino effects stoping the world when there is a cascade of counters reaching zero.

The optimisatios needed to improve such scenarions, are akin to a poor man's tracing GC implementation.

replies(1): >>46029199 #
6. winrid ◴[24 Nov 25 01:14 UTC] No.46029199{4}[source]▶
I didn't forget. That's predictable. It happens when the application code does something, or stops doing something, as opposed to the moving collector just doing it at random times.