Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • As an aside, it's just silly to make the repository a bunch of checked-in patches. Git already does revision control. You don't need to do revision control in your revision control.
  • Those are big improvements!
  • Woah nice thought! :) good idea
  • So this is like a cache? Reminded me of https://turborepo.dev for TS, is it a similar concept?
  • Huh, I kinda thought something like this was already being done, but perhaps it was a bit later stage. Neat!

    A kind of related shower thought I had, could rustc not instantiate generic methods, but write out what it expects to find (std::Vec<String>::push), and a separate build process listens to these, but makes sure already built ones are not built multiple times from the whole build.

    I don’t actually know how much of duplication there usually is, but I had gotten the impression that it would be part of the problem.

    Of course I’m no compiler engineer, and I’m sure there are complications like per crate build profiles, etc.

  • Excited to see if there is a path to getting this in the mainline compiler
  • I wonder how this works when a crate's type checking does indeed depend on the bodies of one of its dependency. For example `-> impl Trait` return types famously leak the `Send`/`Sync`-ness of the type, so for type checking their uses you first need to resolve the concrete type behind and hence type checking the body of the function, which seems to go against the core idea of this proposal.

    I guess you could type check the bodies of only these functions, or duplicating this work in the dependencies, but this will likely have further complications especially since this will also apply to all `async fn`s.

  • There’s an interesting comment thread (including potential downsides) about this technique in the submission for “How to speed up the Rust compiler in September 2026” from a couple days ago: https://news.ycombinator.com/item?id=49923594

Explore Birbla archives