4 ms·
> 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 uti
by cxr 6mo ago
> 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?
- adgjlsfhk1 6mo agobuy 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
- nlitened 6mo agoNo, rewriting in any language is bad by itself. What Fil-C gives you is that you don’t need to rewrite old programs. You spend zero effort, and immediately your battle-tested program is memory safe and free of any potential future vulnerabilities. With Rust you spend man-years on a rewrite, and as a result you have a new untested program full of subtle bugs, which you need to spend another 10 years of real-world use to uncover.
- adrianN 6mo agoRewriting in c# is a lot more work than recompiling. That’s the point.
- IshKebab 6mo agoI 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.
- cxr 6mo ago> Rust does so much more than preventing runtime memory errors. It sure does. Like making your build times slower (and bigger) than if you were using the equivalent tooling for Pascal, C, or Zig.
- aw1621107 6mo ago> than if you were using the equivalent tooling for Pascal, C, or Zig. I think GP is talking about not-directly-related-to-safety things like sum types/pattern matching/traits/expressive type systems/etc. given the end of that paragraph. I don't think you can get "equivalent tooling" for such things the languages you list without raising interesting questions about what actually counts as Pascal/C/Zig.
- cxr 6mo agoI know what they were talking about. It was clearly intended to be a cheerfest for Rust. > I don't think you can get "equivalent tooling" for such things the languages you list without raising interesting questions about what actually counts as Pascal/C/Zig. I said builds. All of the languages I mentioned have "equivalent tooling" for that (i.e. compilers—to produce builds for the programs you choose to write in those languages).
- aw1621107 6mo ago> I said builds. All of the languages I mentioned have "equivalent tooling" for that (i.e. compilers—to produce builds for the programs you choose to write in those languages). Oh, my mistake. Given the context I thought you were talking about some hypothetical tooling that gave you something approaching Rust's feature set.
- IshKebab 6mo agoNobody is saying Rust is perfect. I could point out many many flaws in Pascal, C and Zig too. Besides Rust's compile time is actually fairly reasonable these days. Certainly not fast, but better than C++ and people have tolerated that for decades, so it's hardly a deal-breaker.