Comment by vorador 2 days ago
There's a contingent of rust fans that show up on every story about C – their premise is that C code is unsafe and most safety-critical C code should be rewritten in rust.
Fil-C is new and is a viable competitor to rust, that's why you're hearing all asides about tiny niches, unacceptable performance degradation, etc.
> Fil-C is new and is a viable competitor to rust
I’ve no horse in the race here, but the Fil-C page talks about a 4x overhead from using it, which feels like it would make it less competitive
I tried it on my primes micro-benchmark (http://hoult.org/primes.txt) and got a 2:1 slowdown on 13th gen i9.
It does a LOT of array access and updating, probably near to worst-case for code that isn't just a loop copying bytes.
The average slowdown is probably more in the same region as using Java or C# or for that matter C++ std::array or std:vector.
If you missed it, djb himself posted this cute graph of "nearly 9000 microbenchmarks of Fil-C vs. clang on cryptographic software (each run pinned to 1 core on the same Zen 4)":
https://cr.yp.to/2025/20251028-filcc-vs-clang.html
I've heard Filip has some ideas about optimizing array performance to avoid capability checks on every access... doing that thread safely seems like an interesting challenge but I guess there are ways!
Sure of course I followed that link. I've really got no idea what the horizontal axis is! But there is a huge cluster of results between 1x and 1.5x execution time.
And, the kind of code he is interested in is not necessarily the same as the kind of code I'm interested in. In fact I know it's not!
As one more data point, compiling my little benchmark with gcc, without any optimisation flag.
1964ms gcc primes.c -o primes -O
3723ms fil-c primes.c -o primes -O
3753ms gcc primes.c -o primes
16334ms fil-c primes.c -o primes
There’s no Rust fans here, only GC skeptics. GC skeptics existed long before anyone dreamed of Rust and will survive Rust as well.
It’s a pretty reasonable objection too (though I personally don’t agree). C has always been chosen when performance is paramount. For people who prioritise performance it must feel a bit weird to leave performance on the table in this way.
And Jesus Christ, give it a rest with this “Rust fans must be thinking” stuff. It sounds deranged.
No, back in the day C was used for everything. Vim was not written in C because it needed to wring every last bit of performance out of text editing.
Rewriting everything in rust "for memory-safety" is a false tradeoff given the millions of lines of C code out there and the fact that rewrites always introduce new bugs.
Please, I’m begging you, stop talking about Rust. You’re shoehorning Rust into a discussion where it hasn’t been mentioned, just to hate on some imaginary people you think are pushing Rust here. No one is talking about that. You sound deranged and obsessed.
The vast majority of the conversation here is about GC and the performance implications of that. Please stick to the rest of the thread.
I almost always find that building Boehm GC as a malloc replacement (malloc() -> GC_malloc(), free() -> NOP), and then using LD_PRELOAD to get it used makes any random C/C++ program not only still work but also run faster.
Not only that, but you can then use GC_FREE_SPACE_DIVISOR to tune RAM usage vs speed to your liking on a program by program (or even instance by instance) basis, something completely impossible with malloc().
Hacker News is not a place where any one group brigrades a thread. There are people who prefer C who don't want a GC, people who prefer Rust who don't want C, people who prefer Rust who agree with Fil-C for legacy C, people who don't prefer C or Rust and may use languages with GC.... We all have interests and face people who denigrate them in bad faith. If you have specific objections to inaccurate statements in this thread, then state them. I'll do the same for any technology if I'm qualified to make statements on it.