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

Here is the answer I got from vjeux:

> There's a lot of fast web tooling being written in rust those days. https://twitter.com/Vjeux/status/1722769322299609565

I don't buy it. I think vjeux is riding the hype.

To be fair compiled languages are just faster than interpreted (in most cases, and as others have pointed out especially with strings)

Sean Baxter is doing a decent job with his Circle compiler, so I hear. https://www.circle-lang.org/

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.

Would love to hear your opinion about V too especially since one of its main selling points is fast build times:

https://vlang.io/#:~:text=Small%20and%20easy%20to%20build%20...

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

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'm skeptical. Cranelift was designed to do something similar - avoid LLVM and be fast enough for JIT.

It's easy to claim to be fast when you're extremely early on, we'll see how that holds up.

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.

The benchmarks show Mold for both Rust and C++. This wasn't explicitly stated in the article; sorry. https://github.com/quick-lint/cpp-vs-rust/blob/f8d31341f5cac...