Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The next generation of Bazel builds

blogsystem5.substack.com

Post reply on HN
Print view View original

71–80 of 90 posts

Re: The next generation of Bazel builds

#71

Post by anon6362 »

sepositus wrote: post #42
eej71 wrote: post #37

Earlier quoted context omitted.

I'm glad to see someone else describe their experience this way too. bazel has arrived at $WORK and it has been a non-trivial amount of work for even the passionate advocates of bazel. I know it was written by the Very Smart People at google. They are clearly smarter than me so I must be the dummy. Especially since I never passed their interview tests. :-) Of course given all things google, by the time I'm fully onbo…

> know it was written by the Very Smart People at google For Google. That's the key. I have the privilege of experiencing both sides, having been at Google for nine years. I never had a problem with Blaze, but using Bazel in a smaller company has been extremely painful. I think there are just very few places that have the exact problems as Google where something like Bazel would be a great fit.

That's the rub. It provides scalability for very large organization, of which, there are few. It's similar to running OpenStack. Meta also has some projects like this, such as buck2 which lacks the really good virtual FS acceleration stuff (eden). Megacorp FOSS tend to skew towards offering whizbang features that are incomplete, complicated, poorly documented, and require a lot of extra work.

Re: The next generation of Bazel builds

#72

Post by anon6362 »

zokier wrote: post #5

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

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.

Re: The next generation of Bazel builds

#73

Post by anon6362 »

kridsdale1 wrote: post #49

In the 2020s I have used BUCK, BUCK2, and Blaze every working day. I don’t feel like getting in to details but I’ll just say that BUCK2 is the best of the 3 and I’m delighted it’s open source. I don’t have experience with Bazel as it exists externally but I expect the internal Blaze has advanced far beyond it by now as the entire Google engineering world depends on it.

https://github.com/facebook/sapling/tree/main/eden

I'm still unsure if a complete, viable eden solution was released with all of its necessary components.

Re: The next generation of Bazel builds

#74

Post by anon6362 »

jeffbee wrote: post #19

I find anyone this dismissive of Java hard to take seriously. Java is a cutting-edge language platform where the achievable performance at the limit is on-par with C++. Also, the article's hook didn't grab me. My laptop is way, way more powerful than any "beefy workstation" they ever assigned me at Google, starting with a dual-core 2400MHz Opteron. Bazel's server performance on my laptop or workstation are total non-…

Proper, dependency-aware build caching makes or breaks a build system. Meta's buck2 builds tend to be crazy fast because of this and it can also do synthetic checkouts with arc/"hg" via eden.

Re: The next generation of Bazel builds

#75

Post by bloppe »

kerbs wrote: post #62
LegNeato wrote: post #28

As the manager of the original Buck team, rules should not be starlark. They should be `wasm`.

Also dying for an explanation here

Wasm, specifically using the component model [1], is really good for plugin use-cases.

- Polyglot; you can write plugins (in this case Bazel rules) in "any" language, and the component model is easily the best system ever created for cross-language interoperability.

- Ecosystem; tooling is still generally immature, but you'd be surprised how much buy-in there is. Web apps are a huge incentive for language developers to support it, and Wasm now runs in a lot of places besides the browser too. Envoy and Istio support Wasm plugins. So does Postgres. So does neovim.

- Component interfaces are richly typed. You get things like lists, structs, "resources" (aka objects with instance methods), etc. all supported idiomatically in whichever language you're using and these can be used across language boundaries. Even between GC and non-GC languages. Even with Rust's ownership model.

- Plugins are fully sandboxed, so a host can allow plugins to have things like `while` loops while enforcing runtime limits on a per-instruction basis. It also means Bazel doesn't have to invent it's own bespoke sandboxing solutions for every supported platform, as it does today. And Wasm is designed to handle untrusted Web code, so there are tons of security guarantees.

- Performance is already really good, and there's every reason to believe it will get better. Again, Browser support is big here. The things the Chrome team did to optimize V8 are pretty incredible, and they're now turning their attention to Wasm in a big way.

[1]: https://component-model.bytecodealliance.org/design/why-comp...

Re: The next generation of Bazel builds

#76

Post by jeffbee »

lostdog wrote: post #66
jeffbee wrote: post #63

Earlier quoted context omitted.

Literally everyone who uses bazel uses it client-server as a persistent daemon.

And part of why it's a persistent daemon is because Java is slow to start up. I'll note that bazelisk is written in Go.

Exactly. And a Go program that forks a Java program that makes an RPC is still faster than `cargo help`

Re: The next generation of Bazel builds

#77

Post by ewhauser421 »

lihaoyi wrote: post #25

A big problem with Bazel not mentioned here is the complexity. It's just really hard for many people to grasp, and adopting Bazel at the two places I worked was a ~10 person-year effort for the rollout with ongoing maintenance after. That's a lot of effort! IMO Bazel has a lot of good ideas to it: hierarchical graph-based builds, pure hermetic build steps, and so on. Especially at the time, these were novel ideas. Bu…

Bazel is an investment to learn for sure but your effort estimates are way overblown. We have a Python, Go, and Typescript monorepo that I setup for our team and rarely have to touch anything. Engineers rarely think about Bazel as we use Gazelle to generate all our build files and have patterns for most everything we need to do.

Compared with build efforts using other tools and non-monorepo setups at other companies the effort here has felt much reduced.

Re: The next generation of Bazel builds

#78

Post by mgce »

lostdog wrote: post #46

Great article, that gets the critique exactly right. The most frustrating part of Bazel is how shoddy the workmanship is. For example, Bazel throws away your analysis cache when you change flags that have nothing to do with what's being built or how, like flags that change what tests are run. If course the biggest issue is that tiny operations take more time than necessary. For example, at $PreviousJob we wrote custo…

> The most frustrating part of Bazel is how shoddy the workmanship is.

Without commenting on the above statement:

> For example, Bazel throws away your analysis cache when you change flags that have nothing to do with what's being built or how, like flags that change what tests are run.

I don't think this is a good example. Bazel's analysis cache clearing is to preserve correctness in the context of a legitimately algorithmically difficult problem. The fact Bazel has this limitation is a testament toward its correctness strengths. I'm not aware of systems that have solved that algorithmic problem but curious if anyone knows any.

Also Bazel avoids that problem for most "flags that change which tests are run", since that subset of the problem is more solvable. --test_env was a notable exception, which was fixed (https://github.com/fmeum/bazel/commit/eb494194c1c466f7fd7355...) but not sure if it's in the latest Bazel release yet? But generally changing --test* has much smaller performance impact.

Re: The next generation of Bazel builds

#79

Post by joshuamorton »

sunshowers wrote: post #65
jeffbee wrote: post #63

Earlier quoted context omitted.

Literally everyone who uses bazel uses it client-server as a persistent daemon.

Demonization introduces a range of potential cache invalidation issues. The issues are solvable, but whose KPIs depend on getting to the bottom of them?

Do you have specific examples in the context of blaze/bazel here? I think "the set of cache invalidation issues" you're describing are basically "the set of cache invalidation issues blaze/bazel intends to solve", so the answer to "whose KPIs" is "the blaze team".

Re: The next generation of Bazel builds

#80

Post by aseipp »

lihaoyi wrote: post #25

A big problem with Bazel not mentioned here is the complexity. It's just really hard for many people to grasp, and adopting Bazel at the two places I worked was a ~10 person-year effort for the rollout with ongoing maintenance after. That's a lot of effort! IMO Bazel has a lot of good ideas to it: hierarchical graph-based builds, pure hermetic build steps, and so on. Especially at the time, these were novel ideas. Bu…

I care a ton about fast and accurate build systems but one issue I think we haven't solved is that: people do not want to use other build tools for their language. "Why isn't it Cargo? Why not use NPM/Yarn? Why not use Pip? Why not CMake?" These questions are often rhetorical because they do not care about build systems. They don't care about the design. They don't care if your CI could be 5x faster. You will never make them care. It's good enough. You must have absolutely zero externalized cost (and therefore put in a lot of effort) to get over this hurdle. There's seemingly no way around it.

The reason a lot of people like Bazel is, I think, tools like Gazelle -- which reduce that whole problem back to "Run gazelle" and all the crap is taken care of for you. Dependencies, BUILD files, etc. People constantly talk about the "complexity" aspect, but very few people appreciate how complex Cargo, NPM, Yarn, Cabal, Dune, internally are. Because they just run "build", and it works. Bazel, Buck2, Mill, etc will all have this problem unless huge effort is put in.

TBH, this is one of the reasons why I think Nix has wildly succeeded in the past few years while more fine-grained and scalable systems have had adoption problems -- despite its numerous, numerous flaws. You get to Bring-Your-Own-Build-System, and Nix along with the blood of 10,000 upstream contributors keeps the juice flowing, and it's cached and hermetic so you see real savings. That greatly eases people into it. So they adopt it at all points on the curve (small, medium, huge projects), because it works with what they have at all those points. That makes them willing to get deeper and use the tool more.

Post reply on HN