I'd be interested to hear what system/field/language you use with compilers that come with guarantees that they will never, ever introduce performance regressions for compile times under any circumstances (presumably with a hefty SLA to match), and where the addition of e.g. an extra innocuous header by some other part of your team will never never ever introduce unexpected nonlinear compile times that require investigations of what the compiler is spending times on.
I suspect this only applies to an extremely small portion of real world code and projects (direct hand optimised asm, perhaps something like forth?)
As far as I am aware the only "guarantees" (interpreting "vow" to mean this) with rust are that edition-bound code will continue to compile correctly, modulo bugs which may be introduced/need fixing.
Of course, it feels like rust could do better, the reputation it has hasn't come from nowhere, but, personally, it's a far cry from e.g. the projects I work on, where we are mandated (by inter-company politics) to use a custom SCons atrocity on C++ that takes two minutes to run a no-op build.
Naturally having scons written in Python has nothing to do with it.
Re:Why is my Rust build so slow?
by mustache_kimono on Friday December 31, 2021 @03:52PM
(#29752415)
I thought this level of entitlement was restricted to open source users, not devs. AFAIK Rust never promised anything re: the compile-time performance of its standard library, and I know of no 3rd party library that does. You link in a 3rd party library, then that's your code now for better or for worse.
I'd argue that when it comes to doing work, I only want to deep-dive into my code. Not third party libraries that "vow" to have been tested + performant, let alone the language/build tools themselves.