But sure, twice as fast isn't fast, it's just faster. My point is that we're not at the point of serious diminishing returns, there's tons of stuff left to do.
It is a knock on Rust. The circumstances of Rust's state of existence in 2023, as a language created in this millennium but not in the last decade, are an absurdity.
> I doubt it’s possible to do what Rust does—including zero overhead abstractions—in a fast compiling language
People packaging releases for software written in Rust and others who are passive consumers and finding themselves downloading the repo to compile from source for whatever reason (e.g. because the creators don't do binary releases themselves) don't need "Rust" (i.e. the official build toolchain) to do the things that active contributors (who want to be yelled at about borrow checker violations) need from it.
I'd call this oversight a massive lack of imagination on the part of TPTB behind Rust, but that would be wrong, because there is no need to imagine the differences between these use cases. They exist. An adequate toolchain for dealing with projects written in Rust—despite the deliberate decisions made during the design of the language that led to these problems—does not.
Sorry, could you be more vague?
Anyway, your post seems to be about packaging software? Or something? Confusing since that has nothing to do with the language...
Yes, I can, since "2023", "this millennium", and "in the last decade" are all concrete, well-defined things that lead to basically no ambiguity.
This is not a knock on Rust—I doubt it’s possible to do what Rust does—including zero overhead abstractions—in a fast compiling language. Go certainly pays a performance penalty with things like boxed generics.