alt Hacker News> In Fil-C: compile those dependencies with Fil-C, and then the whole process is safe.
Great work on Fil-C by the way. Very technically impressive stuff!
It seems like the competition for Fil-C is other garbage collected languages. Rust will always outperform Fil-C, with the caveat that rust allows unsafe blocks, raw pointers and raw C FFI. But if you’re happy to ditch performance and the ability to do bare metal systems level programming, why Fil-C over Go or C#?
If you want a safer, less convenient dialect of rust, that also exists. Just don’t use or depend on any unsafe code in your program. (There are 3rd party tools to check this). More and more C libraries are getting pure rust ports these days. It’s increasingly rare to actually need to pull in C libraries at all. Sticking to safe rust is a bit inconvenient - but I suspect so is using fil-c. I suppose with fil-C you can use any libraries you want, you’ve just gotta recompile them. That’s cool!
Rust has a bunch of unsafe code in std, so you’re still at risk of a bug there causing safety problems. But the same is true of Fil-C.
I could definitely see myself reaching for Fil-C when running legacy code. It’d be nice if there was a way to use fil-C to protect my rust program from memory bugs in C dependencies. But I can think of dozens of ways why that would be tricky to pull off.
Also I’m curious - can Fil-C protect against threading bugs like rust can? Rust has Send & Sync traits to mark which objects can be safely shared between threads. I can’t think of a way to do that in an automated way without help from the programmer.
Replies
> More and more C libraries are getting pure rust ports these days.
I don't think these rewrites will ever be mainstream. There is so much C out there, and typically ports focus on the 90% that is easy to write and neglect the remaining 10%.
> It seems like the competition for Fil-C is other garbage collected languages. Rust will always outperform Fil-C, with the caveat that rust allows unsafe blocks, raw pointers and raw C FFI. But if you’re happy to ditch performance and the ability to do bare metal systems level programming, why Fil-C over Go or C#?
Say you wanted to write a tool like sudo in C# or Go. Here's what would happen: you'd end up having to rely on dependent libraries, like pam, which then relies on other things like libselinux and libaudit. And libselinux depends on pcre2. Those things would be compiled with Yolo-C, so while your sudo tool's new code written by you would be safe, the process would mostly contain unsafe code.
But if you write sudo in Fil-C, then you can rely on all of those dependencies being compiled with Fil-C. The whole process is safe.
So, the reason why you'd pick Fil-C is that it's actually memory safe for real, unlike the alternatives, which just give you safety for newly written code but pull in a ton of unsafe depenendencies.
> If you want a safer, less convenient dialect of rust, that also exists. Just don’t use or depend on any unsafe code in your program. (There are 3rd party tools to check this).
That's impractical for the reasons above.
> Also I’m curious - can Fil-C protect against threading bugs like rust can?
Not like Rust can, but yes, it does.
Fil-C preserves memory safety under races. This means that debugging multithreaded C/C++ programs in Fil-C is a much nicer experience than in Yolo-C. If you do something wrong, you're going to get a panic - similar to how multithreading bugs in Java or C# lead to exceptions.
But, unlike Rust, Fil-C does not attempt to ensure race-freedom for your own logic.