The next generation of Bazel builds
blogsystem5.substack.com
The next generation of Bazel builds
1–10 of 90 posts
Re: The next generation of Bazel builds
#2Mentions Buck, but no mention of Pants or Please.
Re: The next generation of Bazel builds
#3Mentions Buck, but no mention of Pants or Please.
The author clarifies that he wrote the section about Buck2 to demonstrate the need to be Bazel compatible (as opposed to Buck2), because the friction to try it out in a real code base is essentially insurmountable.
Re: The next generation of Bazel builds
#4>On the other hand, we need a tiny build system that does all of the work locally and that can be used by the myriad of open-source projects that the industry relies on. This system has to be written in Rust (oops, I said it) with minimal dependencies and be kept lean and fast so that IDEs can communicate with it quickly. This is a niche that is not fulfilled by anyone right now and that my mind keeps coming to;
Yes please!
Re: The next generation of Bazel builds
#5I find the dismissal of buck2 pretty shallow. Most of the world is not already heavily invested to bazel, so compatibility is imho overstated; I don't see it being that far-fetched for something like buck2 to leapfrog bazel. That being said, buck2 definitely would need some love from outside meta to really be viable competitor, right now it still feels like half-complete code drop
Re: The next generation of Bazel builds
#6>On the other hand, we need a tiny build system that does all of the work locally and that can be used by the myriad of open-source projects that the industry relies on. This system has to be written in Rust (oops, I said it) with minimal dependencies and be kept lean and fast so that IDEs can communicate with it quickly. This is a niche that is not fulfilled by anyone right now and that my mind keeps coming to; Yes…
[deleted]
Re: The next generation of Bazel builds
#7>On the other hand, we need a tiny build system that does all of the work locally and that can be used by the myriad of open-source projects that the industry relies on. This system has to be written in Rust (oops, I said it) with minimal dependencies and be kept lean and fast so that IDEs can communicate with it quickly. This is a niche that is not fulfilled by anyone right now and that my mind keeps coming to; Yes…
Everyone says they want a "tiny" "minimal" "lean" build-system, but there is lots of real complexity in these areas:
- Cross-compilation and target platform information
- Fetching dependencies
- Toolchains
I'm not sure a system that solves these would still be considered minimal by most, but those are table-stakes features in my view.
If you don't need these things, maybe stick with Make?
Re: The next generation of Bazel builds
#8I find the dismissal of buck2 pretty shallow. Most of the world is not already heavily invested to bazel, so compatibility is imho overstated; I don't see it being that far-fetched for something like buck2 to leapfrog bazel. That being said, buck2 definitely would need some love from outside meta to really be viable competitor, right now it still feels like half-complete code drop
I agree. The biggest issue with Buck 2 for me (apart from documentation) is the lack of something like bzlmod. There's actually a decent number of modules available for Bazel now:
https://registry.bazel.build/all-modules
But with Buck2 you're stuck with `http_archive` and vendoring.
Re: The next generation of Bazel builds
#9I find the dismissal of buck2 pretty shallow. Most of the world is not already heavily invested to bazel, so compatibility is imho overstated; I don't see it being that far-fetched for something like buck2 to leapfrog bazel. That being said, buck2 definitely would need some love from outside meta to really be viable competitor, right now it still feels like half-complete code drop
I agree. The biggest issue with Buck 2 for me (apart from documentation) is the lack of something like bzlmod. There's actually a decent number of modules available for Bazel now: https://registry.bazel.build/all-modules But with Buck2 you're stuck with `http_archive` and vendoring.
bzlmod feels better at first but you're left navigating version conflicts anyways.
Vendoring deps is the only true real sane way for large repos
Re: The next generation of Bazel builds
#10One thing not mentioned is the massive amount of complexity and difficulty involved in Starlark rules. In the next generation of build tools, I really wish Starlark could be replaced with some subset of TypeScript, which would have drastically better IDE support. And I wish the typing would be done in such a way that it's harder to do things that are bad for performance. Starlark is super difficult to read, navigate, and write, and there are a lot of performance gotchas.
I know there are efforts like starpls (language server for Starlark) but in my experience it really falls short. I think buck2 has type annotations but I kind of hate Python-style types, so I wish we could just use TypeScript :P TypeScript is even better positioned to fill this role now that tsc is being re-written in Go.