Comment by vlovich123
10 hours ago
I don’t know what you mean by SafER but it’s important to remember that Fil-C sacrifices a lot of performance for that safety which detracts the reasons you’d be running that software as otherwise C was a bad language for them. Sometimes this won’t matter but there are places fil-c won’t be able to go that Rust can - embedded and OS kernel come to mind. Other places would be things like browsers or games. Rust gives you the safety without giving up the ability to do performance.
Also, I could be wrong but I believe any assembly linked into Fil-C bypassed the safety guarantees which would be something to keep in mind (not a big deal generally, but a source of hidden implicit unsafe).
I’m apparently comment happy on this OP, but, the typing of it looks funny because it starts the sentence, I’m pretty sure OP was saying safER, as opposed to SAFE (as in totally safe instead of comparatively safer). I have been quite charitable to OP in some sibling comments and will do so here. I think OP is attempting to give Fil-C some credit for being an attempt to increase the overall memory safety of existing code without incurring the complexity of a new language or the complexity of rewriting long running/widely distributed code. It is a decent sentiment and a viable methodology to achieve a laudable goal, but is certainly susceptible to caveats like the performance penalty you mention.