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

No, 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.

Rewriting in c# is a lot more work than recompiling. That’s the point.

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.

> 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.

> 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.

I 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).

> 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.

Nobody 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.

> I could point out many many flaws in Pascal, C and Zig

Yes. They're flawed. Everyone knows, but great detective work.

> Rust's compile time is actually fairly reasonable these days. Certainly not fast, but[…]

That's not reasonable.

Golang's compile times with the official toolchain are fast, despite the compiler being self-hosting and all the criticisms about the suboptimal code that its emitter produces. So with the official golang compiler being one such low-quality binary, by any reasonable measure, one should be able to expect the official Rust toolchain to be at least as fast. (Unless the explanation for that is as simple as that they just never give a shit about compile times. And I gotta say, I'm kind of getting the feeling that that might be the case. But it's still early days—Rust is a brand-new project after all—so maybe we should wait until it's at least a few years old before we come to any conclusions.)

And none of this addresses the demands on other resources, like memory—which was somehow deemed important somewhere near the root of this thread. (I guess that's not the case anymore, somehow.)

It's not that they don't care about compile times. Clearly they do. It's just that a lot of decisions were made that favour other things over compile time (e.g. runtime performance).

> That's not reasonable.

Most people think it is. You're in the minority there.

> Most people think

Oh yeah? Have you done a study on this?

I used to have one hour builds with C back in 1999 - 2002, for each of our target platforms, Aix, HP-UX, Solaris, Windows NT/2000, Red-Hat Linux, multiplied by Informix, Oracle, Sybase SQL Server, MS SQL Server, ODBC bindings.

A new product release would take a full day.