What is the actual catch with Fil-C? Memory safety for C based projects without a complete rewrite sounds like a very good idea, but there must be some pitfalls in this approach which this would not work in some cases.
In some other memory-safety circles (Rust, Zig, etc) I'm going to expect that this is going to be heavily scrutinized over the claims made by the author of Fil-C.
It sounds like Fil-C combines the ergonomics of C with the performance of Python.
It might have a beautiful niche for safely sandboxing legacy code. But I don’t see any compelling reason to use it for new code. Modern GC languages are much more ergonomic than C and better optimised. C#, Java, JavaScript and Go are all easier to write, they have better tooling and they will probably all perform as well or better than Fil-C in its current state.
I was reading the `fontconfig` source recently (to help me understand what, exactly, is the difference between the various `fc-*` tools and their options) and some of the code scared me.
I thought, "for sure this is a use-after-free" ... but it happened to be safe because some function performed an undocumented incref, and the return value of that function was kept alive.
So this is definitely a high priority thing to port!
... I suppose the interesting question is: if some of my dependencies are ported, and some are not, is there any way a normal compiler can call into a Fil-C-compiled library for just a few functions?
6 comments
[ 3.0 ms ] story [ 27.8 ms ] threadIn some other memory-safety circles (Rust, Zig, etc) I'm going to expect that this is going to be heavily scrutinized over the claims made by the author of Fil-C.
But great work on this nonetheless.
It sounds like Fil-C combines the ergonomics of C with the performance of Python.
It might have a beautiful niche for safely sandboxing legacy code. But I don’t see any compelling reason to use it for new code. Modern GC languages are much more ergonomic than C and better optimised. C#, Java, JavaScript and Go are all easier to write, they have better tooling and they will probably all perform as well or better than Fil-C in its current state.
I thought, "for sure this is a use-after-free" ... but it happened to be safe because some function performed an undocumented incref, and the return value of that function was kept alive.
So this is definitely a high priority thing to port!
... I suppose the interesting question is: if some of my dependencies are ported, and some are not, is there any way a normal compiler can call into a Fil-C-compiled library for just a few functions?