Thread

1. azkalam · 1790019824 · focus · HN ↗

   If you can pay the setup cost, Bazel will get you build times ~10s with a warm cache for even massive projects.

   1. seniorsassycat · 1790024655 · focus · HN ↗

      Bazel seems to have a lot of tradeoffs, from setup time of the sandbox for each task, to ergonomics that lead folks to maintain parallel 'normal' tooling.

      Plus, 'with a warm cache' is doing heavy lifting, what's the real cache hit rate for a week of development? Investing in improving the cold build and frequent actions is still important with bazel or any incremental builder.

      I'm not sure it's useful to talk about bazel broadly, it's actual performance and behavior comes down to the rules you use. You can configure bazel like turbo/nx and cache tsc/vitest/eslint on each package.json module, and get course cached units that are evicted on every change, or you can use gazelle and target per-file actions which are only invalidated when their dependencies change. But that trades off batching unless you use workers.

      1. sluongng · 1790055460 · focus · HN ↗

         What i have seen on my end is that it’s pretty easy to setup a cloud coding agent with a warm Bazel cache. “Warm” here can means multiple layers: same disk to CoW/hardlink, different disk, network disk/block devices, same rack/datacenter, same AZ, etc…

         And yes, there are a ton of investments going toward Bazel recently to unlock these newer use cases.

Unofficial Hacker News client; not affiliated with Y Combinator.