That's the policy, but we've been a bit more conservative in practice. `main` currently targets 1.88, but that's only because a security issue in the time crate has forced our hand (one reason I don't like the time crate all that much). Before that, it was 1.83 (from November 2024). Our last release targets 1.71 (from July 2023).
I think the way Rust checks borrows also makes it a lot more feasible to avoid allocations/copies; not because it is impossible to do in C, but because doing it in C requires writing very careful documentation and the caller to actually read that documentation. In (safe) Rust this is all checked by the compiler such that libraries can leverage it without blowing their complexity budget.
There’s also a compounding effect: I’ve heard from a hardware vendor that they spend a lot of time optimizing OpenSSL to get the most out of their silicon, so for their customers they suggest using OpenSSL to get the most out of the hardware.
Both bloggers know each other (this is pretty obvious if you read some of their online stuff), so Dan Luu probably reviewed the other post early and thought it interesting enough to add his own take.
Good throughput with GC seems to come with significant extra memory use:
"We compare explicit memory management to both copying and non-copying garbage collectors across a range of benchmarks using the oracular memory manager, and present real (non-simulated) runs that lend further validity to our results. These results quantify the time-space tradeoff of garbage collection: with five times as much memory, an Appel-style generational collector with a non-copying mature space matches the performance of reachability-based explicit memory management. With only three times as much memory, the collector runs on average 17% slower than explicit memory management. However, with only twice as much memory, garbage collection degrades performance by nearly 70%."
AIUI the crates are actually linked to the account via a different identifier, not directly to the username.