strager

> 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.

Unfortunately, we live in the real world where compilers do not do the things that you suggest that they ought to.

I'm not sure what you mean. Are you talking about the benchmarks?

I run `cargo clean` before each benchmark. That should clean up changes to third-party crates, right?

I'd love to try Zig and Jai for this purpose, but they are not stable yet. If either becomes stable, I'll happily re-run this experiment.

Nim doesn't look like the language for me.

> Definitely check [Val and Carbon] out if you're looking for a C++ replacement!

I don't want to base my project on an experimental language like Carbon or Val.

I want a C++ replacement which compiles quickly. Do Carbon or Val compile quickly? If not, I don't know why you mention these languages.

> If your main conclusion is based on full builds, i would urge you to re-evaluate.

It's not. I show several charts comparing incremental builds too.

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.

> 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.