I always find BazelCon to be an exceptional experience, and this year was no exception. From the things I learned by randomly talking to people, to meeting familiar faces and learning from the talks and BOF sessions, it is simply an incredible experience. Today I want to go over some things I observed and what I am looking forward to in Bazel 10.

AI is everywhere

Nowadays, when we are all using AI agents every day, I find that using AI is becoming just like using any other tool. There was no talk about doomsday scenarios, but rather encouragement to use AI even more. On more than one occasion, people would say “point your agent at the documentation” instead of reading the documentation yourself. Also, EngFlow’s report on how much people are using AI was eye-opening. It’s not like I didn’t expect it, but seeing the numbers really puts things into perspective.

IDEs as we know them are going away

It seems that nobody is focusing on IDEs as much as we did before. For example, we’ve seen the use of rules_xcodeproj going down in some large organizations in favor of more lightweight alternatives like VS Code. I feel like the next opportunity for IDEs is a more integrated code review experience and better code navigation. Investing heavily in better autocomplete seems wasteful since fewer people are relying on it as their primary way of writing code. Sure, it is always good to have it in some shape or form, but I don’t expect it to be the main focus of IDE improvements in the coming years.

Bazel 10

Bazel 10 continues the effort of moving language-specific functionality out of the core and into Starlark extensions. There are also a lot of welcome performance improvements, some of which are being accelerated by the use of AI.

Project Skymetal

This is an effort to replace parts of Bazel’s Java implementation with native code, currently focusing on Rust. It is going to take some time, as the Bazel team won’t simply replace all Java with Rust overnight. Instead, the plan is to migrate component by component, using JNI to bridge Java and Rust. Early results are promising, but I expect we’ll get a better picture of how it plays out once more of the codebase has been migrated.

Skycache

Skycache is basically an attempt to remotely cache Bazel’s analysis state, which is becoming more expensive to compute over time, especially in larger monorepos. This effort started last year, and by the looks of it, it is gaining more traction. In fact, Google is already experimenting with an early implementation internally, though their results do not automatically translate to analysis caching for everybody, as Google relies on infrastructure such as its cloud-based filesystem.

Stripping native flags

Rulesets like those for Apple platforms have historically relied on Bazel’s native flags for CPU selection and various other things. The effort to remove these language-specific flags from Bazel core is continuing, with equivalents being provided through Starlark-based configuration, including the apple_support module.

Talks and other relevant information

Snapshotting Bazel server state

This is an interesting approach to snapshotting the entire Bazel server state so that we don’t have to pay the analysis cost every time. Of course, this can be fragile, but I believe it can be useful if done carefully.

Hermetic LLVM

Hermetic LLVM got a lot of attention during this BazelCon, and I think it is well deserved. David and Corentin did an amazing job of providing a fully hermetic C/C++ toolchain, which has always been a challenge in Bazel. Hopefully, this finally puts the issue to rest.

rules_rs

Similar to Hermetic LLVM, rules_rs is getting a lot of well-deserved attention due to its fast Cargo dependency resolution and strong emphasis on hermeticity.

Sandbox on macOS

Of course, it is well known that Bazel sandboxing on macOS is not as performant as on Linux, so folks over at Aspect have been working on providing a way to plug in a custom sandboxing binary. Hopefully, someone finds a way to finally make sandboxing on macOS as fast as it is on Linux.

Any to Bazel

This is a quick note on any2bazel, a tool developed by EngFlow that aims to help humans and AI agents migrate projects to Bazel. It uses a deterministic approach to compare what the original build system actually compiles and links against what Bazel produces. This helps guide agents toward a correct migration, because simply getting a green build is not enough.

Apple Birds of a Feather

The last time we had an Apple BOF was in Mountain View, California. This time, there was a lot of discussion about excessive disk usage in tests when statically linking dependencies. The quick fix is to use dynamic frameworks, but that comes at the cost of slower startup times and potentially other issues. Another popular topic was Linux-to-macOS remote build execution (RBE), where Linux is used as the CI runner and macOS machines as remote executors. This effectively allows us to initiate builds from Linux while executing Apple-specific build actions on macOS. There was also a discussion about building Apple targets directly on Linux, but the potential licensing issues make this approach unappealing to large organizations. Of course, the Apple BOF would not be complete without mentioning Swift explicit modules support in rules_swift. Thank you, Keith, for doing the work!

Conclusion

There you have it. Yet another incredible BazelCon behind us, and I am already looking forward to the next one. P.S. I know I haven’t covered a lot of ground here, but these are just my quick notes and observations.