You make a really good point about C++ headers. Textual inclusion of globs of bytes into translation units is 1970s legacy stuff that totally fucks up reasonable build times, and for all the talk about C++20 modules they haven't delivered yet.

I actually think this is one of the things that Rust could crush C++ on, because build times are becoming the whole show on big C++ projects.

It's super weird to me that C++, with this whacky 1970s constraint that totally fucks up modularity, still builds neck-and-neck or better with Rust.

In principle Rust could do *way* better on this, and that is a feature that might get me to consider Rust seriously, no matter how stupid I think the borrow checker is. But Rust still compiles dog slow...

>It's super weird to me that C++, with this whacky 1970s constraint that totally fucks up modularity, still builds neck-and-neck or better with Rust.

Not so fast! The compilation and linking is neck and neck with Rust so you can have an ELF in the same amount of time. But then you have to run all the C++ tools you mentioned to have parity with what the Rust compiler is doing.

> for all the talk about C++20 modules they haven't delivered yet.

Even when they're delivered, will all the libraries you depend on use them?

>In principle Rust could do way better on this, and that is a feature that might get me to consider Rust seriously, no matter how stupid I think the borrow checker is. But Rust still compiles dog slow...

The team that built the Borrow Checker deserves the Turing Award. It is an outstanding bit of computer science and engineering. I'm surprised that you think it's stupid.

It used to be dog slow but it's gotten very fast in the past two years. Another achievement.

>In principle Rust could do way better on this, and that is a feature that might get me to consider Rust seriously

Modules? Your take away from all this is that modules are the killer feature of Rust and that the Borrow Checker is stupid?

I call shenanigans. You are an elaborate troll. Well done for getting two responses out of me.

I find if you're aware about how you define your modules, incremental compiles are usually pretty quick. Yes a complete build can take a while but tools like sccache[0] can help with that in CI pipelines and when getting a new dev environment up.

[0]: https://github.com/mozilla/sccache

I have the opposite problem with rust dependency management, its too easy so you get deep widely branching dependency trees by differing authors with differing licenses. From a corporate use perspective this is a legal nightmare. From a security standpoint, this is a trust nightmare.

For licenses there's cargo-deny https://github.com/EmbarkStudios/cargo-deny

On the security standpoint and a wide net of crates.. that's a problem, same as with npm/yarn/pip/whatever and I agree on that. That one bugs me as well. Difficult to audit.

Cargo-deny is accurate, but it accepts no legal or financial risk if it was in some case wrong and you infected a codebase with gplv3, and thus corporate lawyers everywhere ignore it.

Edit: this post keeps getting up and down voted. I suspects it has to do with the phrase infected by gplv3. I like the license fine, but being realistic many businesses treat it like radioactive waste, so that has to be a consideration

In fairness, you have those problems no matter how you include other people's code. At least Cargo as far as I'm aware uses a SAT-solver to deliver you a working dep graph unlike `pip` or `npm` or any of that nonesense. (as long as I remember correctly that Carl Lerche wrote that part. Sidebar: wicked smart guy).

You do, but clunky dependency management meant fewer less granular dependencies.