4 ms·

It is a single file, but when you include header files which get dropped in they can get to many hundreds of thousands of lines of code in practice per correspo

It is a single file, but when you include header files which get dropped in they can get to many hundreds of thousands of lines of code in practice per corresponding .o file.

saurik 3y ago
But the level of parallelism possible is downright insane with C++ because of this property... once, out of anger at my build time on something I was working on back in 2016/2017, I set up a AWS Lambda as a compilation server (fully generic: all it had was my toolchain, not the code in question or even the build scripts) for something akin to ccache and successfully managed to build my project with a pipeline (I use that word as I was still doing the preprocessing locally) of at least a hundred simultaneous jobs: good luck ever pulling that off with Rust. It is also generally very easy to break apart any file or decouple any header files using various techniques that don't affect your project layout or require any mental maintenance once done. In contrast, with Rust, you have to essentially refactor what your project even "means" to pull that off as you now need to be juggling a ton of microcrates (and then it seems like there is some inherent crate overhead so this becomes a painful tradeoff plane you need to optimize; compilation units have to become degenerated small before that matters in C++). And, even then, the remaining slowest file in my insanely complex C++ project does tend to take a ridiculously long time to build (I have a 30-60 second long compile for one small component) and I have run out of low-hanging fruit; but, I honestly hardly ever actually have to build it: the coupling of header files is massively overstated as when you are in a tight build/update cycle you are generally modifying a single function in a source code file, not changing some header file of basic data types that will affect the code generation of literally the entire rest of the project. Like, I get it: thinking about code as a merged set of linear forward passes is sometimes annoying, but it doesn't just enable massive gains in compile time... it also encourages more legitimate coupling between components as circular dependencies require extra code and upkeep for prototypes and that's good because circular dependencies are bad. Rust thereby is doing something that frankly feels super awkward: it is elevating behavior that frankly makes more sense only within a single file or at best a single object to a project organizational unit, which suddenly makes this all seem much more complicated to handle correctly.

It is a single file, but when you include header files which get dropped in they can get to many hundreds of thousands of lines of code in practice per corresponding .o file.

saurik 3y ago

But the level of parallelism possible is downright insane with C++ because of this property... once, out of anger at my build time on something I was working on back in 2016/2017, I set up a AWS Lambda as a compilation server (fully generic: all it had was my toolchain, not the code in question or even the build scripts) for something akin to ccache and successfully managed to build my project with a pipeline (I use that word as I was still doing the preprocessing locally) of at least a hundred simultaneous jobs: good luck ever pulling that off with Rust. It is also generally very easy to break apart any file or decouple any header files using various techniques that don't affect your project layout or require any mental maintenance once done. In contrast, with Rust, you have to essentially refactor what your project even "means" to pull that off as you now need to be juggling a ton of microcrates (and then it seems like there is some inherent crate overhead so this becomes a painful tradeoff plane you need to optimize; compilation units have to become degenerated small before that matters in C++). And, even then, the remaining slowest file in my insanely complex C++ project does tend to take a ridiculously long time to build (I have a 30-60 second long compile for one small component) and I have run out of low-hanging fruit; but, I honestly hardly ever actually have to build it: the coupling of header files is massively overstated as when you are in a tight build/update cycle you are generally modifying a single function in a source code file, not changing some header file of basic data types that will affect the code generation of literally the entire rest of the project. Like, I get it: thinking about code as a merged set of linear forward passes is sometimes annoying, but it doesn't just enable massive gains in compile time... it also encourages more legitimate coupling between components as circular dependencies require extra code and upkeep for prototypes and that's good because circular dependencies are bad. Rust thereby is doing something that frankly feels super awkward: it is elevating behavior that frankly makes more sense only within a single file or at best a single object to a project organizational unit, which suddenly makes this all seem much more complicated to handle correctly.