[pizlonator]

Custom libc does not call to system libc.

“Custom” and “system” aren’t the terms I use; I say user libc and you libc (because they are basically the same libc - either both are musl or both are glibc).

User libc calls to the Fil-C runtime, which filters syscalls, and those filtered syscalls are made via yolo libc.

Hence, a Fil-C program is memory safe down to the syscalls and syscalls cannot be used to escape the protections (unless you do weird stuff with /proc)

[wasmperson]

The way I see it, as far as memory safety is concerned that's just framing. Both Fil-C and Rust have a boundary below which the unsafe lives. If Fil-C is only safer than rust when you don't pass the `-F unsafe_code` argument to rustc then IMO "safer" in this case is somewhat of an empty claim.

[flumpcakes]

I think you should watch the linked presentation, it will show how it is "safer" than rust. Unfortunately there are performance implications, but fil-c seems fast enough to go into production for many workloads and surprisingly needs very little code changes to existing C/C++ projects which is a huge benefit.

[josephg]

I think Fil-C might make a lot of sense for running legacy C or C++ codebases. But for new code, it seems like it’s trying to compete with other GC languages. Take away C’s performance advantages and I don’t know why anyone would use it.

Fil-C: Combining the ergonomics of C with the performance of Python!

[uecker]

I like using C. It is simple, elegant, has very fast compilation times, requires no FFI needed for many libraries, is extremely stable and extremely portable, a large ecosystem, and, most importantly, I do not think the ergonomics of C are bad.

It is inconvenient to start using it as it comes with basically nothing out of the box, but this is irrelevant after a short time using it.

[pizlonator]

Fil-C is much faster than Python

And it’s fun to write new code in.