Comment by cachius
6 hours ago
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.
Thank you so much for sharing this. I missed the HN post.
This is beautiful!
Why would I want to run a garbage collector and deal with it's performance penalties?
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.
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.
1 reply →
> Because about 99% of the time the garbage collect is a negligible portion of your runtime
In a system programming language?
7 replies →
For new projects, I just use Rust: there is zero reason to deal with a garbage collector today. If I'm in C, it's because I care about predictable performance, and why I'm not using Java for that particular project.
3 replies →
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.
You also pay for the increased throughput with significant memory overhead, in addition to worst-case latency.
1 reply →
> in Java garbage collector actually speeds up memory management compared to C++ if you measure the throughput
If I had a dollar for every time somebody repeated this without real-world benchmarks to back it up...
Java (w/ the JIT warmed up) could possibly be faster than C++, if the C++ program were to allocate every single value on the heap.
But you're never going to encounter a C++ program that does that, since it makes no sense.
I see this claim all the time without evidence, but it's also apples and oranges. In C++ you can avoid heap allocations so they are rare and large. In java you end up with non stop small heap allocations which is exactly what you try to avoid when you want a program to be fast.
Basically java gc is a solution to a problem that shouldn't exist.
Easy: because in your specific use-case, it's worth trading some performance for the added safety.
If I'm in C, I'm using JNI to work around the garbage collector of Kava
1 reply →