[flagged]
Fil-C is an important tool to secure traditional software but it doesn’t yet compete with Rust in the places it’s competing with C and C++ in greenfield projects (and it may never - that’s ok - it’s still valuable to have a way to secure existing code without rewriting it).
And I disagree with the characterization of Graydon’s blog. It’s literally praising Fil-C and saying it’s a valuable piece of tech in the landscape of language dev and worth paying attention to as a serious way to secure a huge amount of existing code. The only position Graydon takes is that safety is a critically important quality of software and Fil-C is potentially an important part of the story of moving the industry forward.
I'm not sure how you read it that way? To me it reads like "yes, this is a good and notable thing even if it's not perfect".
(The creator of Fil-C is also in this thread and doesn't appear to be reading it that way...)
This post is very polite compared to what I've seen from some Rust fanatics. But it still strikes me as talking down to the C and C++ community, as if these languages are beyond redemption because they don't work the same as Rust.
This post is borderline or lowkey Rust propaganda IMO. You might disagree with that but you're not going to convince me there is no campaign.
It also seems reasonable that Rust programmers would feel threatened by anything that makes C and C++ safer and more usable. While there is some benefit to comparing and contrasting different solutions to memory safety, this guy is clearly biased.
> If anything, Rust zealots sure aren't hiding, their agenda is deep-set and out in the open, and they are generally obnoxious.
You really need to drop the paranoia.
If you think my outlook is paranoid or whatever, you should take it up with the Rust community, not me.
So far as I've seen, Graydon is not a zealot and he doesn't play political games. It was a shame to lose his guiding hand
Graydon Hoare is the creator of Rust.
So of course he likes Rust. And of course his blog post is going to be comparing Fil-C to Rust. Anyone can write a blog post evaluating Fil-C, but only Graydon can compare it to his own design choices and motivations when he attempted to solve a similar problem. That's the whole thing that makes this post interesting.
Rust with 1/4 of the speed doesn't feel like 90% of the benefits of Rust. I'm sure the author will make Fil-C faster in time, but Rust is always going to be much faster.
Let me put it another way. We could say that documentation, code formatting, and even profiling, all have a place in development. So would running a model checker or something. But we don't generally make compilers implement these features and make that a mandatory part of the build. I think the complex memory borrowing scheme of Rust unnecessarily forces the compiler to check a lot of extra stuff specific to a certain class of problem. You don't get a choice about how paranoid you need to be about errors. You just have to eat that long compile time, every time.