cargo

You can do cargo install --locked ripgrep_all as a workaround. It uses the lockfile that's part of the ripgrep_all package, so you miss out on some package updates, but can also get the cachedir version required. There is a github issue to make this the default behaviour of cargo, but you miss out on updates which might fix security bugs so the cargo team is unwilling to change the default. https://github.com/rust-lang/cargo/issues/7169

I believe so, as cargo defaults to the number of cores, as per this issue: https://github.com/rust-lang/cargo/issues/2805 For what it's worth, this guy noticed a nearly 2x speedup in compiling OpenSSL, which is C code, so I assume GCC or Clang: https://twitter.com/sandofsky/status/1331732592958214145 This suggests, though it does not prove, that the performance improvement for code compilation is likely not exclusive to a single language.

Hmm apparently there is a cargo feature for it now: https://github.com/rust-lang/cargo/blob/master/src/doc/src/r... So something like this in .cargo/config: [doc.extern-map] std = "local" And then cargo +nightly doc -Zrustdoc-map.

> unfortunately, Cargo merges dependencies and devDependencies in a way that’s simply incorrect. Yeah, I've run into that, but IIRC this got solved super recently/is being solved. Probably https://github.com/rust-lang/cargo/pull/7820 ?

>People adopted Cargo because it is nice to use. I don't think it's that simple and I want people to really dissect what the "nice to use" means. I contend that a fully funded backend ("crates.io" on Heroku+S3) is essential to make cargo a viable tool. A programming language ecosystem needs a Schelling Point (or a disproportionately influential C++ vendor dictating industry-wide tool usage) and the C++ ecosystem doesn't have that. We can't replay history with an alternate events since cargo and crates.io came together but let's try a thought experiment and think of cargo in isolation: Let's say we believe cargo's nice usage syntax (and not crates.io) is the what really drives adoption. Ok, let's hypothetically clone the github/cargo project and modify it to C++ (e.g. process ".cxx", "cpp" files instead of ".rs" files. I don't think th

This reminds me of the ongoing saga of RUSTC_BOOTSTRAP[0][1] The stable compiler is permitted to use unstable features in stable builds, but only for compiling the compiler. In essence, there are some Rust features that are supported by the compiler but only permitted to be used by the compiler. Unsurprisingly, various non-compiler users of Rust have decided that they want those features and begun setting the RUSTC_BOOTSTRAP envvar to build things other than the compiler, prompting consternation from the compiler team. [0] https://github.com/rust-lang/cargo/issues/6627 [1] https://github.com/rust-lang/cargo/issues/7088

> Anyone know what happened around 2019-09-01, when all the compile times dipped quite a bit in the graph? The dip is roughly in the center between 2019-07-01 and 2019-09-01, so I'd say it was somewhere in the start of August. As the usual suspect for speed improvements nnethercote seems to have gotten no merged PRs in that date range, I suspect it's the impact of pipelined compilation [1]. The PR that enabled it for rust's nightlies [2] was merged on Aug 1 so the date would fit quite well. [1]: https://github.com/rust-lang/cargo/pull/7143 [2]: https://github.com/rust-lang/rust/pull/63181