So, a few things, some of which others have touched on:1. Fil-C is slower and bigger. Noticeably so. If you were OK with slower and bigger then the rewrite you should have considered wasn&#x27;t to Rust in the last ten years but to Java or C# much earlier. That doesn&#x27;t invalidate Fil&#x27;C&#x27;s existence, but I want to point that out.2. You&#x27;re still writing C. If the program is finished or just occasionally doing a little bit of maintenance that&#x27;s fine. I wrote C for most of my career, it&#x27;s not a miserable language, and you are avoiding a rewrite. But if you&#x27;re writing much new code Rust is just so much nicer. I stopped writing any C when I learned Rust.3. This is runtime safety and you might need more. Rust gives you a bit more, often you can express at compile time things Fil-C would only have checked at runtime, but you might need everything and languages like WUFFS deliver that. WUFFS doesn&#x27;t have runtime checks. It has proved to its satisfaction during compilation that your code is safe, so it can be executed at runtime in absolute safety. Your code might be wrong. Maybe your WUFFS GIF flipper actually makes frog GIFs purple instead of flipping them. But it can&#x27;t crash, or execute x86 machine code hidden in the GIF, or whatever, that&#x27;s the whole point.

Not here, lots of discussion:Fil-Qt: A Qt Base build with Fil-C experience (143 points, 3 months ago, 134 comments) <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46646080">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46646080</a>Linux Sandboxes and Fil-C (343 points, 4 months ago, 156 comments) <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46259064">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46259064</a>Ported freetype, fontconfig, harfbuzz, and graphite to Fil-C (67 points, 5 months ago, 56 comments) <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46090009">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=46090009</a>A Note on Fil-C (241 points, 5 months ago, 210 comments) <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=45842494">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=45842494</a>Notes by djb on using Fil-C (365 points, 6 months ago, 246 comments) <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=45788040">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=45788040</a>Fil-C: A memory-safe C implementation (283 points, 6 months ago, 135 comments) <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=45735877">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=45735877</a>Fil&#x27;s Unbelievable Garbage Collector (603 points, 7 months ago, 281 comments) <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=45133938">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=45133938</a>

&gt; write memory-unsafe code, just now it is guaranteed to crashIf it&#x27;s guaranteed to crash, then it&#x27;s memory-safe.If you dislike that definition, then no mainstream language is memory-safe, since they all use crashes to handle out of bounds array accesses

By that token, Rust is also memory unsafe: array bounds checks and stack overflow are runtime checks.

What&#x27;s the alternative?<a href="https:&#x2F;&#x2F;play.rust-lang.org&#x2F;?version=stable&amp;mode=debug&amp;edition=2024&amp;gist=ab648af31586d776004fd9296e276106" rel="nofollow">https:&#x2F;&#x2F;play.rust-lang.org&#x2F;?version=stable&amp;mode=debug&amp;editio...</a>

For some things the just-crash is ok, like cli usage of curl

Rust also has run-time crash checks in the form of run-time array bounds checks that panic. So let us not pretend that Rust strictly catches everything at compile-time.It’s true that, assuming all things equal, compile-time checks are better than run-time. I love Rust. But Rust is only practical for a subset of correct programs. Rust is terrible for things like games where Rust simply can not prove at compile-time that usage is correct. And inability to prove correctness does NOT imply incorrectness.I love Rust. I use it as much as I can. But it’s not the one true solution to all things.

The issue with Fil-C is that it&#x27;s runtime memory safety. You can still write memory-unsafe code, just now it is guaranteed to crash rather than being a potential vulnerability.Guaranteed memory safety at compile time is clearly the better approach when you care about programs that are both functionally correct and memory safe. If I&#x27;m writing something that takes untrusted user input like a web API memory safety issues still end up as denial-of-service vulns. That&#x27;s better, but it&#x27;s still not great.Not to disparage the Fil-C work, but the runtime approach has limitations.

Minor nitpick. Or confusion on my part. In the filc_malloc function the call to calloc doesn&#x27;t seem to allocate enough memory to store an AllocationRecord for each location in visible_bytes. Should it be:<pre><code> ar-&gt;invisible_bytes = calloc(length, sizeof(AllocationRecord));</code></pre>

Thanks for the love man!&gt; &quot;rewrite it in rust for safety&quot; just sounds stupidTo be fair, Fil-C is quite a bit slower than Rust, and uses more memory.On the other hand, Fil-C supports safe dynamic linking and is strictly safer than Rust.It&#x27;s a trade off, so do what you feel

Exactly, the Venn diagram of programmers using c&#x2F;c++ and programmers who can use a garbage collector for their workload is two circles.

&gt; Fil-C is one of the most unrated projects I&#x27;ve ever seenWhen&#x27;s the last time you told a C&#x2F;C++ programmer you could add a garbage collector to their program, and saw their eyes light up?

You’re not wrong but both problems could be alleviated by sending patches :-)

&gt; it slows programs downInteresting, how costly would be hardware acceleration support for Fil-C code.

Fil-C has two major downsides: it slows programs down and it doesn&#x27;t interoperate with non-Fil-C code, not even libc. That second problem complicates using it on systems other than Linux (even BSDs and macOS) and integrating it with other safe languages.

It makes more sense for new software to be written in Rust, rather than a full rewrite of existing C&#x2F;C++ software to Rust in the same codebase.Fil-C just does the job with existing software in C or C++ without an expensive and bug riddled re-write and serves as a quick protection layer against the common memory corruption bugs found in those languages.

Fil-C is much slower, no free lunch, if you want the language to be fast and memory safe you need to add restrictions to allow proper static analysis of the code.

I write C++ for my job everyday, and claiming Fil-C does the same thing as Rust (and that people who do rewrites in Rust are stupid) sounds braindead.I love Fil-C. It&#x27;s underrated. Not the same niche as Rust or Ada.

Fil-C is one of the most unrated projects I&#x27;ve ever seen. All this &quot;rewrite it in rust for safety&quot; just sounds stupid when you can compile your C program completely memory safe.

This is yet another variant of the &quot;fat pointers&quot; technique, which has been implemented and rejected many times due to either insufficient security guarantees, inability to cross non-fat ABI boundaries, or the overhead it introduces.

A simplified model of Fil-C