3 ms·

I 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 be

by zokier 2y ago

I 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

IshKebab 2y ago
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 https://registry.bazel.build/all-modules But with Buck2 you're stuck with `http_archive` and vendoring.
- setheron 2y ago
  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
- keddad 2y ago
  Seems like a non-issue to me. I work with a relatively large Bazel monorepo, and we have to vendor pretty much anything anyways. Many 3rd-party rules might need patches to work properly with our custom toolchains/rules. Bzlmod sounds nice for small projects, but for big monorepos within organizations with established processes it is more of a hassle, and I imagine that most Bazel users are not using it for small projects.
  - IshKebab 2y ago
    Yeah it's more of an issue for small projects. But I don't think Buck/Bazel should be reserved for megarepos with thousands of contributors. Why can't small projects use it?
- aseipp 2y ago
  To be honest, I'd rather not see Buck2 repeat the mistakes of Bazel so early on, especially when it took a lot of time before settling on bzlmod. Frankly, I'd rather it go the other way: just have a gigantic 'buck2pkgs' repo that has everything inside of it -- literally fucking everything -- just like Nix and Nixpkgs have done. I've watched and committed to Nixpkgs for over 10 years now and I think being a monorepo has massively contributed to its success, ease of contribution, and general usability. And in practice it means 99% of projects only need one "dependency" and they are done and have everything they could want. In theory a buck2pkgs could even be completely divorced from Meta's existing Prelude, because you can just reimplement it all yourself, without being constrained by their backwards compatibility with Buck1. That would reduce the surface area between the two projects substantially and let you do a lot of huge cleanups in the APIs. I actually started doing this a while back but it is of course a massive amount of work. I do think it's a much better way to go, though...
dlahoda 2y ago
yeah. author misses that buck2 is nix like. seems he is in mind of prev gen assembly systems.
liminal 2y ago
Buck2 doesn't seem to support JS/TS, so it's not ready for our use case.
- zokier 2y ago
  In what sense do you mean support? buck2 is afaik completely language agnostic, you can use it to drive any compilers/tools you want?
  - fire_lake 2y ago
    Probably means a lack of out of the box rulesets. Writing your own rules to use a build system for a typical project is an unrealistic ask, IMO.
jen20 2y ago
The biggest problem with everything NotBazel in this space is IDE support. JetBrains have already moved their build for IntelliJ to it, and are aggressively adding native first party support.
anon6362 2y ago
I miss Meta's arc + buck2 + eden + "hg" + "phabricator" + testing infrastructure that does a lot of acceleration of builds, testing, and landing commits without rebasing.

by zokier 2y ago

IshKebab 2y ago

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 https://registry.bazel.build/all-modules But with Buck2 you're stuck with `http_archive` and vendoring.

setheron 2y ago
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
keddad 2y ago
Seems like a non-issue to me. I work with a relatively large Bazel monorepo, and we have to vendor pretty much anything anyways. Many 3rd-party rules might need patches to work properly with our custom toolchains/rules. Bzlmod sounds nice for small projects, but for big monorepos within organizations with established processes it is more of a hassle, and I imagine that most Bazel users are not using it for small projects.
- IshKebab 2y ago
  Yeah it's more of an issue for small projects. But I don't think Buck/Bazel should be reserved for megarepos with thousands of contributors. Why can't small projects use it?
aseipp 2y ago
To be honest, I'd rather not see Buck2 repeat the mistakes of Bazel so early on, especially when it took a lot of time before settling on bzlmod. Frankly, I'd rather it go the other way: just have a gigantic 'buck2pkgs' repo that has everything inside of it -- literally fucking everything -- just like Nix and Nixpkgs have done. I've watched and committed to Nixpkgs for over 10 years now and I think being a monorepo has massively contributed to its success, ease of contribution, and general usability. And in practice it means 99% of projects only need one "dependency" and they are done and have everything they could want. In theory a buck2pkgs could even be completely divorced from Meta's existing Prelude, because you can just reimplement it all yourself, without being constrained by their backwards compatibility with Buck1. That would reduce the surface area between the two projects substantially and let you do a lot of huge cleanups in the APIs. I actually started doing this a while back but it is of course a massive amount of work. I do think it's a much better way to go, though...

dlahoda 2y ago

yeah. author misses that buck2 is nix like. seems he is in mind of prev gen assembly systems.

liminal 2y ago

Buck2 doesn't seem to support JS/TS, so it's not ready for our use case.

zokier 2y ago
In what sense do you mean support? buck2 is afaik completely language agnostic, you can use it to drive any compilers/tools you want?
- fire_lake 2y ago
  Probably means a lack of out of the box rulesets. Writing your own rules to use a build system for a typical project is an unrealistic ask, IMO.

jen20 2y ago

The biggest problem with everything NotBazel in this space is IDE support. JetBrains have already moved their build for IntelliJ to it, and are aggressively adding native first party support.

anon6362 2y ago

I miss Meta's arc + buck2 + eden + "hg" + "phabricator" + testing infrastructure that does a lot of acceleration of builds, testing, and landing commits without rebasing.