5 ms·

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

• deleted 11mo ago
  [deleted]
• 762236 11mo ago
  Why would I want to run a garbage collector and deal with it's performance penalties?
  • palata 11mo ago
    Easy: because in your specific use-case, it's worth trading some performance for the added safety.
    • 762236 11mo ago
      If I'm in C, I'm using JNI to work around the garbage collector of Kava
      • palata 11mo ago
        Have you ever measured the performance impact of JNI? :-)
  • jerf 11mo ago
    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.
    • hypeatei 11mo ago
      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.
      • KerrAvon 11mo ago
        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.)
        • lelanthran 11mo ago
          > 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. Maybe; I sometimes write non-hobbyist non-performance-critical code in C. I'm actually planning a new product for 2026 that might be done in C (the current iteration of that product line is in Go, the previous iteration was in Python). I've few qualms about writing the server in C.
          • josephg 11mo ago
            > I've few qualms about writing the server in C. Bad Unicode support. Lack of cross platform system libraries. Needing to deal with CMake / autotools / whatever. Poor error handling. No built in string, list or map types. No generics. Nullability. No sum types. No option, tuples or multi returns. Generally worse IDE support than a lot of languages. No good 3rd party package ecosystem. The modern idiocy of header files. Memory bugs. Debugging memory corruption bugs. … I mean, yeah other than all those problems, C is a great little language.
            • lelanthran 11mo ago
  • sesm 11mo ago
    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.
    • zozbot234 11mo ago
      You also pay for the increased throughput with significant memory overhead, in addition to worst-case latency.
      • KerrAvon 11mo ago
        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).
    • dataflow 11mo ago
      > 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...
      • jesse__ 11mo ago
        I wish I could upvote this 100 times
    • CyberDildonics 11mo ago
      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.
  • cryptonector 11mo ago
    Because C is very unsafe, but there are still many billions of lines of C in use, so making C safer is a great idea.
• mk89 11mo ago
  Thank you so much for sharing this. I missed the HN post. This is beautiful!