there's a wonderful blog post about this that I wish I could find and can't. I feel like it was a github gist.
The gist of it is something like:
- Bazel community hits a problem with something like how npm behaves around paths
- Bazel's solution is to create a patching system around paths to resolve them
- rinse and repeat for every piece of tooling us "normies" are using
The end result is that instead of Bazel's efforts showing up in the base tooling, they build up a bunch of their own tooling and patches, and the underlying tools don't get really much if any benefit. Moving to Bazel still is a PITA, and there's a lack of improving onramps
In an alternate universe when people in Bazel land hit issues they would show up with patches and recommendations _to the underlying tools_ to get things merged in so that the workflows can be better supported across the board.
I don't think anyone working on Bazel is against upstreaming, but I think they discount the value of it because, hey, _they_ can get patches and hacks working for their flow
Ah interesting, thanks.
My intuition is that npm, cargo, zig build etc are all “wrong”. And that Bazel/Buck are architecturally correct. Build systems should be polyglot by default! All these build systems and package managers that are per language are wrong.
But unfortunately Bazel and Buck have a decade plus of tech debt and baggage from their corporate overlords. Internal buck is actually mostly nice. I don’t know why anyone ever use it externally.