> Ideally type-checking, linting, highlighting and formatting would run in one language service doing incremental parsing and updates to a shared AST on every keystroke.
I think this is the reason Biome (originally called Rome) started. Rome's vision was a shared toolchain to yield better performance and to fix config hell.
Good question. The author of Zig claims that dev build times will be amazing. One technique is to avoid LLVM. Another technique is to integrate the linker. But all of that is a work-in-progress project.
> I don't know enough C++ or Rust to judge but is it possible that they are optimized around Rust that isn't C++ style? I know I have seen articles about other languages where some very minor changes make a huge difference because the optimizations in place didn't understand what was happening and had to work harder.
Are you talking about run-time optimizations? My article is focused on build times. I don't think what you mentioned applies to build times. I could be wrong, though. (There are certainly compile time traps you can fall into, but I wouldn't know what those are in Rust.)
> And did you try any of the optimization strategies again at 24x? I would be curious if there are differences there.
No, I did not. That's a good suggestion. But I was pretty tired of this project by the time I made the scaling benchmarks. xD
I have found Clang's -ftime-trace flag helpful in finding bloated #include-s and templates. Also, I have analyzed the .ninja_log file (for CMake+Ninja) to find slow-to-compile .cpp files.
> They seem to have chosen to use mold for C++ and not for Rust after seeing that it gave little benefit for small projects, but I would expect that to change as the project scales.
> I’m very confident that Rust would fare considerably better with 24 17.1k-line crates (410k lines, larger due to duplicating the entire thing rather than just the lexer) than with the one 104.4k-line crate apparently tested.
I didn't consider this in my scaling benchmark. You make a good point.
> if I want faster development (among other things), I use an interpreted scripting language. If I want a fast end product (among other things) I compile and optimize to machine code beforehand
I want both. I was hoping Rust would give me both, but it doesn't.
> I assume it also reduces size of created object-files?
Normal template instantiations are deduplicated by the linker. Total object file size is smaller with explicit template instantiations, but the size of the final executable is the same with both styles.
> I just randomly looked at one part: linked vector.
How would Rust LinkedVector's implementation have fewer lines than C++'s linked_vector?
> It would be a great experiment to use lots of external libraries. You might find that the code doesn't get slower (build times would probably go up though )
Build times going up is a great reason why I would not use external libraries!
> A recent change[0] on nightly rustc might help with incremental builds.
I tested with rustc Git commit c7572670a1302f5c7e245d069200e22da9df0316, which (I think) includes that change.
> And for repeated clean + full build cycles there's sccache[1].
You're right. I included full builds in the article because almost-full builds happen a lot in C++ (after common certain header files, or if you think the build system broke something).
I imagine almost-full builds rarely happen when working in Rust though, so maybe I should have deemphasized my full-build benchmarks.
I think this is the reason Biome (originally called Rome) started. Rome's vision was a shared toolchain to yield better performance and to fix config hell.