Fil-C introduces a garbage collector and can result in significant slowdowns in some cases. Its main existence reason is making non-perf sensitive C/C++ memory safe, not improving the language design. If really want your stack to be C/C++ & Fil-C then your competition includes D/Nim/Go/etc, not (just) Rust/Zig. Even if it magically made C/C++ memory safe, no downsides, your question basically boils down to C vs C++ vs Rust. Don't know about you but prefer somewhat larger binaries and some compiler brawling over programming 70s style.

Both are great tech but solve the problem of safety differently. I would say Fil-c is great for non-performance-critical (think like somewhere between c and go/java, still very fast) existing C programs where compatibility with the existing program / security is a big concern. think ffmpeg, nginx, sudo.

Fil-c:

- You have a great existing c program that may have memory bugs, and you wanna make it safer.

- Or you wanna write a new program in c, and be extra sure it's safe and don't mind a little performance penalty.

- Or you wanna find subtle memory bugs by building your c program with fil-c (asan style) and disable it for performance in your release build.

Rust is great when you want to build a new codebase from scratch, and have the time and patience to deal with the borrow checker. It also gives you some thread safety, (which is different from memory safety) at the development time cost of dealing with the borrow checker. Rust:

- A new codebase where you need multithreading and safety, and want excellent performance

- You need a broad ecosystem of existing packages

- Your problem space benefits from a robust type system.

Fil-C aborts your program if it detects unsafe memory operations. You very much can write code that is not memory safe, it will just crash. Also it has significant runtime cost.

Rust tries to prevent you from writing memory-unsafe code. But it has official ways of overcoming these barriers ("unsafe" keyword, which tells compiler - "trust me bro, I know what I'm doing) and some soundness holes. But beause safety is proven statically by compiler, it is mostly zero-cost. ("Mostly" because some things compiler can't prove and people resort to "unsafe" + runtime checks)

Two orthogonal approaches to safety. You could have Fil-C style runtime checks in Rust, in principle.