> What's the option if I want to learn Bazel to an intermediate level and I don't work with former Googlers?
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.
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.