←back to thread

271 points mithcs | 4 comments | | HN request time: 0.001s | 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 #
jstimpfle ◴[] 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 #
1. pjmlp ◴[] 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 #
2. mbac32768 ◴[] No.45960892[source]
Could you name two of these that are important to you?
replies(2): >>45961147 #>>45961871 #
3. cryptonector ◴[] No.45961147[source]
Or even one. I know there are operating systems in use that are not written in C, but the major ones are written in C. And anyways, it's not just the OS. There's a pile of C code. Fil-C is a fantastic idea. I think Fil is going to make it good enough to use in production, and I badly want to use it in production.
4. pjmlp ◴[] No.45961871[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.