|
|
|
|
|
by pornel
263 days ago
|
|
Another aspect is that the majority of projects that keep using C, do it specifically to maximize performance or low-level control (codecs, game engines, drivers, kernels, embedded). For such projects, a GC runtime goes against the reason why they used C in the first place. Rust can replace C where Fil-C can't. A technically memory-safe C with overhead is not that groundbreaking. It has already been possible with sandboxing and interpreters/VMs. We've had the tradeoff between zero-overhead-but-unsafe and safer-but-slower languages forever, even before C existed. Moving C from one category to the other is a feat of engineering, but doesn't remove the trade-off. It's a better ASAN, but not miraculously fixing C. Most projects that didn't mind having a GC and runtime overhead are already using Java, C#, Go, etc. Many languages are memory-safe while claiming to have almost C-like performance if used right. The whole point of Rust is getting close to removing the fast-or-safe tradeoff, not merely moving to the other side of it. |
|
The thing that is interesting about Fil-C isn’t that it’s a garbage collected language. It’s that it’s just C and C++ but with all of the safety of any other memory safe language so you can have a memory safe Linux userland.
Also, Fil-C isn’t anything like ASAN. ASAN isn’t memory safe. Fil-C is.