←back to thread

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

(hwisnu.bearblog.dev)
271 points mithcs | 1 comments | 17 Nov 25 10:40 UTC | HN request time: 0s | 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 #
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 #
hypeatei ◴[17 Nov 25 14:10 UTC] 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 ◴[17 Nov 25 15:58 UTC] 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 #
jstimpfle ◴[17 Nov 25 21:00 UTC] No.45958223{5}[source]▶
Productivity, portability, stability, mind-share, direct access to OS APIs... there's a lot of reasons to still use C.
replies(1): >>45958583 #
pjmlp ◴[17 Nov 25 21:33 UTC] No.45958583{6}[source]▶
Only if the OS is written in C, and has its APIs exposed as C APIs to userspace.

Quite a few OSes don't fit that rule.

replies(1): >>45960892 #
mbac32768 ◴[18 Nov 25 02:53 UTC] No.45960892{7}[source]▶
Could you name two of these that are important to you?
replies(2): >>45961147 #>>45961871 #
1. pjmlp ◴[18 Nov 25 06:02 UTC] No.45961871{8}[source]▶
Android, userspace is Java, and what is exposed on the NDK is a tiny portion, as it is only meant for games and implementing native methods for better performance beyond what JIT/AOT do, or bindings to existing libraries.

About 80% of the OS APIs are behind JNI calls, when using the NDK.

iOS, iPadOS, watchOS, the large majority of userspace APIs is based on Objective-C, or Swift, bare bones C is only available for the POSIX leftovers.

You need to call the Objective-C runtime APIs for anything useful as an app that Apple would approve.

For the Plan 9 geeks, Inferno, OS APIs are exposed via Limbo.

For folks that still find mainframes and micros cool, IBM i, IBM z/OS, Unisys ClearPath MCP, Unisys OS 2200.

For retrogaming folks, most 8 and 16 bit home computers.