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