21–30 of 41 posts
We have giant Go monorepo at work. Bazel build. The ex-Google guy who set it up, left. No one around who wants to put in the time to learn it. It seems like a general increase in complexity. It seems to replace the go mod stuff so we have something called gazelle that figured it out and third party ide plug-ins. The plug in for IntelliJ is janky. To top it all off, somehow we managed to get a build that is slow local…
We have giant Go monorepo at work. Bazel build. The ex-Google guy who set it up, left. No one around who wants to put in the time to learn it. It seems like a general increase in complexity. It seems to replace the go mod stuff so we have something called gazelle that figured it out and third party ide plug-ins. The plug in for IntelliJ is janky. To top it all off, somehow we managed to get a build that is slow local…
I did use bazel long ago for c++ and it was quite good at it, but we didn’t have very many dependencies.
> Bazel is designed to be optimal and has perfect knowledge of the state of the world, yet it’s too slow for quick operations. This is one of the biggest challenges where Bazel falls short of non-Bazel tooling for us in the Web development/Node.js world. The Node ecosystem has characteristics that push Bazel scaling (node_modules is 100k+ files and 1GB+), and Bazel's insistence on getting builds correct/reproducible…
It's not unique to Bazel. Nix also struggles with Node.js. I'm not too fond of either solution, but to me, the problem lies in the Node ecosystem, and it seems unlikely a "language-agnostic" tool will ever be able to crack that nut.
We tried Bazel for a java monorepo. Not having good IDE support was a deal-breaker because it would complicate things for onboarding and junior devs
We have giant Go monorepo at work. Bazel build. The ex-Google guy who set it up, left. No one around who wants to put in the time to learn it. It seems like a general increase in complexity. It seems to replace the go mod stuff so we have something called gazelle that figured it out and third party ide plug-ins. The plug in for IntelliJ is janky. To top it all off, somehow we managed to get a build that is slow local…
Sounds like your company has bigger issues than build system ;)
> It seems like a general increase in complexity
Try to support a really big monorepo with existing go.mod tooling and you’ll see that it really isnt
We have giant Go monorepo at work. Bazel build. The ex-Google guy who set it up, left. No one around who wants to put in the time to learn it. It seems like a general increase in complexity. It seems to replace the go mod stuff so we have something called gazelle that figured it out and third party ide plug-ins. The plug in for IntelliJ is janky. To top it all off, somehow we managed to get a build that is slow local…
> No one around who wants to put in the time to learn it Sounds like your company has bigger issues than build system ;) > It seems like a general increase in complexity Try to support a really big monorepo with existing go.mod tooling and you’ll see that it really isnt
Earlier quoted context omitted.
> No one around who wants to put in the time to learn it Sounds like your company has bigger issues than build system ;) > It seems like a general increase in complexity Try to support a really big monorepo with existing go.mod tooling and you’ll see that it really isnt
Go mod inadequate for Go projects?
What's the option if I want to learn Bazel to an intermediate level and I don't work with former Googlers? There's a decent number of Hello World examples around, and I can get moving with some rulesets, but using it for more than toy projects seems to be really hard for me and there's not a lot of intermediate content from what I can tell. There's "Advanced" reference materials, and countless "getting started" tutor…
The best way to learn it would be to use it yourself and try solving problems with it. You don't need an xoogler to learn it, my former company did not have one when we first evaluated Bazel.
There is a very active community Slack and StackOverflow for questions as well.
> rarely is there anything relating to best practices or even what constitutes good rules.
I think rules_go has been a stellar example of what a well-made rule should look like:
- Managing toolchains and stdlib within Starlark
- Provide wrapper around core toolchains to enforce best practices
- Break down a build into fine-grained, reusable actions
- Provide concrete APIs for downstream rules (i.e. graphql, swagger, proto code gen) to consume.
> Seems like most of the hobby community prefers NIX for deterministic builds too, so the situation is not improving for novices like myself who really like the idea of hermitic builds, monorepo's and distributed cache.
Nix figured out the external dependencies story much better than Bazel, much thanks to nixpkgs repo. So naturally, in a fragmented opensource ecosystem, Nix thrives much better.
However, in a closed ecosystem within an enterprise, Bazel provides a more granular approach to managing your build: smaller actions mean finer, more granular caching. It also has a much better set of APIs for distributed builds and build telemetry that folks could depend on from day 1. It's also copying some for Nix playbook with the new Bazel Central Registry resembling nixpkgs.
I think you can learn either build system. Most of the skills and concepts are transferrable: sandboxing, build hermeticity, remote caching, remote build, etc... So you often see some experts in this field being involved in multiple build tools development and not just one.
We have giant Go monorepo at work. Bazel build. The ex-Google guy who set it up, left. No one around who wants to put in the time to learn it. It seems like a general increase in complexity. It seems to replace the go mod stuff so we have something called gazelle that figured it out and third party ide plug-ins. The plug in for IntelliJ is janky. To top it all off, somehow we managed to get a build that is slow local…
We had the same setup, ex-Googler SRE demanded builds be done with Bazel for our Go monorepo. He convinced someone to switch it all over, all builds, deploys, CI, testing, etc were all dependent on Bazel. That person left, and the Bazel stuff was left unmaintained as no one had the interest nor time to learn it. Later Bazel decide to kill off rules_docker and replace it with rules_oci, which means we can no longer up…
Personally, most cases I have seen are caused by a systematic under-investment into developer toolings and infrastructure at the company. Management layers often don't understand the software development assembly lines are not composed of just workers(software engineers), but also tools and machines that enable faster workflows. This often results in some critical processes in the pipeline from code to prod to be maintained by 1 guy: monitoring, alerting, deployments, builds, git etc... and when that 1 guy left, the system failed and the company suffered.
I think successful Bazel adoption in an org is often a signal that the company has grown in size and values its developer's time and happiness. Failure to adopt often means a lack of investment in dev experience in general.