The reason I’m not super excited is based on the widely publicized findings from Google and Microsoft (IIRC) about memory safety issues in their code: The vast majority is in new code.
As such, the returns on running the entire userspace with Fil-C may be quite diminished from the get-go. Those who need to guard against UB bugs in seriously battle-hardened C software in production are definitely a small niche.
But that doesn’t mean it isn’t also very useful as a tool during development.
As a mitigation strategy, that becomes less interesting as the quality of that code increases, but you still pay the full cost regardless of whether there are actually any bugs.
That can certainly be valuable to you, but as a developer, the more interesting proposition is about how not to ship bugs in the first place.
https://news.ycombinator.com/item?id=45790015
https://lists.x.org/archives/xorg-announce/2025-October/0036...
To torture the analogy: perhaps the "returns" are diminishing, but their absolute value is still a few million bucks, I'm happy to take those returns.
This makes perfect sense to me.
Which is why I don't at all understand the current fetish with rewriting things that have been working well for decades in Rust. Such as coreutils. Or apt.
It feels like an almost deliberate crippling of progress by diverting top talent into useless avenues, much like string theory in physics, or SLS/Artemis.
You don't have to be a "top talent" to rewrite old unix utilities. The hard part is writing it safely, which in Rust can be done without "top talent."
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.
Sweet summer child
There really are many people here, with largely diverse opinions. Don't lump people together unless they lump themselves together.
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
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.
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!
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
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.
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.
The vast majority of the conversation here is about GC and the performance implications of that. Please stick to the rest of the thread.
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().