[HN Gopher] BazelCon 2024 Recap
___________________________________________________________________
BazelCon 2024 Recap
Author : kaycebasques
Score : 38 points
Date : 2024-10-23 14:50 UTC (8 hours ago)
(HTM) web link (blogsystem5.substack.com)
(TXT) w3m dump (blogsystem5.substack.com)
| dijit wrote:
| 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" tutorials,
| but rarely is there anything relating to best practices or even
| what constitutes good rules.
|
| 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.
| shaftway wrote:
| Most Google engineers don't do anything more complicated than
| the hello world examples. Probably far less complicated because
| they don't need to do any repo setup, it all just works out of
| the box. Most engineers just make simple java build targets.
| Larger teams would have someone who specializes in tweaking the
| build and writes Skylark rules, but to other engineers they
| just look like simple build targets.
|
| I'd suggest finding an open source project and playing with it
| locally. Try to get everything building and running, including
| unit tests. Make the build as granular as you can. Try to pick
| a project that has a variety of kinds of things that need to be
| built, like Java, C++, Protobufs, etc. Then look for patterns
| in the build targets you wrote and see if you can refactor them
| to simplify it with custom Skylark rules.
| mbarr wrote:
| Selenium has a pretty good Bazel setup which uses a lot of
| different functionality:
|
| https://github.com/SeleniumHQ/selenium/
| hnrodey wrote:
| Any conference recommendations? I'm tracking 2024 and 2025
| software engineering conferences. There are still several marquee
| conferences before year end if that's your thing.
|
| https://www.fullyearcal.com/calendar/iMRr-2l16tI/software-en...
| steven-xu wrote:
| > 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 is in a way its own enemy.
| Bazel needs to set up 100s of thousands of file watchers to be
| correct, but the Node.js ecosystem's "let's just assume that
| node_modules hasn't changed" is good enough most of the time. For
| us, many non-Bazel inner devloop steps inflate from <5s to >60s
| after Bazel overhead, even after significant infra tuning.
| malkia wrote:
| I always wondered, why `node_modules` growing so big (in terms
| of file count) was ever ok. Apart from bazel, having that many
| files sucks anyway.
| aliasxneo wrote:
| 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.
| anothername12 wrote:
| 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 locally, slow on CI.
| Arbortheus wrote:
| 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 update our Golang
| version without a super painful migration where we end up
| breaking production a bunch of times because of quirks in the
| super difficult migration.
|
| Eventually we invested the time to rip the whole thing out and
| replace it with standard Go tooling with a multistage docker
| build for the container image. Everything from running tests,
| using Golang tooling, legibility of builds, CI, and deploys is
| easier.
|
| The best thing we did was remove it and move to standard Golang
| tooling.
| fire_lake wrote:
| I'm guessing the build became much slower due to the lack of
| caching though?
| ninjazee124 wrote:
| 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
| fire_lake wrote:
| I found maintaining IDE files and a Bazel build side by side to
| be surprisingly easy.
|
| It's for sure a weak point with Bazel though.
| pianoben wrote:
| Same experience here; I moved us to Gradle six months ago, and
| like _magic_ all the whining in Slack about our build system
| just... went away.
|
| Turns out, when your build system doesn't occupy 5-15% of your
| teams' working days, they get a lot more done!
| synthos wrote:
| Does anyone have a good summary of the Buck(2) track?
| dcsommer wrote:
| I'd love to hear more about the relationship between Buck2 and
| Bazel such that they share a conference. Sure, they are quite
| similar systems and both use Starlark DSL, but is there a long
| term vision of these projects belonging "together" or even
| merging? Or was Buck2 a one-off guest?
| jmmv wrote:
| Buck 2 was part of the "Build Meetup", not BazelCon, which is a
| more-frequent event that has room for more than just Bazel
| (although it's still pretty focused on Bazel-related topics and
| similar build systems). More details at https://meetup.build/
| sebastos wrote:
| So it's 2024, and the plan is that we're going to wait another
| few years for BSP to be finished before vscode support is
| anything more than a toy?
|
| If their goal is adoption, that is just _awful_ pathfinding.
| Probably harkens the beginning of a death spiral for the project,
| if I'm to make a prediction.
___________________________________________________________________
(page generated 2024-10-23 23:01 UTC)