alt Hacker News> Fil-C is slower and bigger
It's not any slower or (proportionally) bigger compared to the experience you would have had 20 years ago running all sorts of utilities that happen to be the best candidates for Fil-C, and people got along just fine. How fast do ls and mkdir need to be?
Replies
I think the problem with this logic is that it views language performance on an absolute scale, whereas people actually care about it on a relative scale compared to how fast it could be.
If you tell your boss "We spent $1m on servers this month and that's as cheap as its possible to be" he'll be like "ok fine". If you say "We spent $1m on servers this month but if we just disable this compiler security flag it could be $500k." ... you can guess what will happen.
(Counterpoint though: people use Python.)
But counter-counterpoint: Rust does so much more than preventing runtime memory errors. Even if Fil-C had no overhead (or I was using CHERI) I would still use Rust.
buy that logic (which I somewhat agree with), we should be rewriting all of these tools in C# or some similar native gc'd language. C and rust both take on a ton of complexity to squeeze out the last 2x of speed, but if we no longer care about that, we should drop C in a heartbeat