[NIckGeek]

Fil-C is impressive and neat, but it does add a runtime to enforce memory safety which has a (in most cases acceptable) cost. That's a reasonable strategy, Java and many other langs took this approach. In research, languages like Dala are applying this approach to safe concurrency.

Rust attempts to enforce its guarantees statically which has the advantage of no runtime overhead but the disadvantage of no runtime knowledge.

[pizlonator]

Rust attempts to enforce guarantees statically, but in practice fails, because of pervasive use of `unsafe`.

Fil-C doesn't "add a runtime". C already has a runtime (loader, crt, compiler runtime, libc, etc)

[NIckGeek]

> but in practice fails, because of pervasive use of `unsafe`.

Yes, in `unsafe` code typically dynamic checks or careful manual review is needed. However, most code is not `unsafe` and `unsafe` code is wrapped in safe APIs.

I'm aware C already has a runtime, this adds to it.

[Rusky]

The stuff Fil-C adds is on the same footing as `unsafe` code in Rust- its implementation isn't checked, but its surface area is designed so that (if the implementation is correct) the rest of the program can't break it.

Whether the amount and quality of this kind of code is comparable between the two approaches depends on the specific programs you're writing. Static checking, which can also be applied in more fine-grained ways to parts of the runtime (or its moral equivalent) is an interesting approach, depending on your goals.