I am suspicious of anything that claims you can achieve memory safety by pressing a button, with zero code changes required. Part of the reason Rust is frustrating to learn is because it forces you to structure your application a certain way and think of edge cases.
> Fil-C has some limitations. Presently, it only works on Linux/x86_64. Also, it's slow – about 1.5x-5x slower than legacy C. That's in part because of its implementation of a pointer encoding method for tracking bounds and types called MonoCaps, and also overhead from calling conventions and dynamic linking that differ from standard C.
This is the definition of Worse C, and nobody wants nor need that
I am suspicious of anything that claims you can achieve memory safety by pressing a button, with zero code changes required. Part of the reason Rust is frustrating to learn is because it forces you to structure your application a certain way and think of edge cases.
I think it’s a bit naive to think that people who won’t learn Rust will learn a new, stricter variety of C.
Pizlo introduced Fil-C at the Splash 2024 conference last month [1]
[1] https://www.youtube.com/live/_VF3pISRYRc?t=4862s
You can have Nim today.
Nobody wants nor need a worse C
If you want/need C with an optional GC, just use D, it also compile C code
Downvoter, you haven't read the damn article
> Fil-C has some limitations. Presently, it only works on Linux/x86_64. Also, it's slow – about 1.5x-5x slower than legacy C. That's in part because of its implementation of a pointer encoding method for tracking bounds and types called MonoCaps, and also overhead from calling conventions and dynamic linking that differ from standard C.
This is the definition of Worse C, and nobody wants nor need that