What are the differences between Bazel and Gradle?

Question

Google just open-sourced its build tool Bazel. What are the differences between this tool and Gradle? What can it do that Gradle cannot, what does it do better, and what does Gradle do better?

Answer 1

Disclaimer: I work on Bazel and I'm not intimately familiar with Gradle. However, one of my coworkers wrote up a comparison of the two systems, which I will paraphrase here:

Bazel and Gradle emphasize different aspects of the build experience. To some extent, their priorities are incompatible - Gradle’s desire for flexibility and non-obtrusiveness limits the restrictions it can place on build structure, while Bazel's desire for reliability and performance necessarily enforces non-negotiable restrictions.

Gradle does value the same principles that Bazel does, i.e. the Gradle team pays great attention to performance (incremental builds, parallelized configuration and execution, the Gradle daemon), correctness (content-based “up-to-date” checking), and reproducibility (rich support for declarative syntax, dependency versioning, explicitly declared dependencies). And Bazel respects the need for flexible project layouts.

The nuance is that Gradle wants to promote good practice while Bazel wants to require it. Gradle aims for a middle ground between the Ant experience (freedom to define your own project structure with incoherent results) and the Maven experience (enforced best practices with no room for varying project needs). Bazel believes that flexible project support is possible without sacrificing the strong guarantees that enable its powerful workflows.

Neither philosophy is more “correct” - whichever tool best suits a project depends on that particular project’s values.

Gradle Overview

Gradle is a highly flexible system that makes it easy for users to construct complete, reliable build flows with minimal constraints on how they organize their projects. It does this by supplying powerful building blocks (e.g. automatic dependency tracking and retrieval, tightly integrated plugin support) with a generic, Turing-complete, scripting interface that can combine these blocks however the users wants.

Gradle emphasizes the following features:

• Easy migration from other systems. Gradle easily accommodates any project organization to easily implement arbitrary workflow structures. It natively understands Ant tasks, and natively integrates with Maven and Ivy repositories.
• Highly extensible scripting model. Users implement all build logic by writing Groovy scripts. A “build” is simply a dependency-sequenced execution of generic tasks, which are essentially open-ended, overridable, extensible method definitions.
• Rich dependency management. Versioned dependencies can be declared and automatically staged from external code repositories, local filesystems, and other Gradle projects. Build outputs can likewise be auto-published to repositories and other locations.
• Tightly integrated plugin system. Plugins are simply bundles of tasks organized to facilitate a desired workflow. Many of Gradle’s "core" features are actually implemented through plugins (e.g. Java, Android). Plugins interact (at their discretion) tightly with build script logic. Plugins enjoy deep access to Gradle’s core data structures.

Bazel Overview

Bazel evolved out of the need to build internal Google projects reliably and efficiently. Because Google’s development environment is unusually large and complex, Bazel offers unusually strong guarantees about the integrity of its builds and unusually low performance overhead in achieving them.

This provides a foundation for powerful development workflows built around reproducible builds, where a “build” becomes an abstract entity that can be referenced, repeated, passed around to different machines, and passed to arbitrary programs and services such that every instance is known to be exactly the same.

Bazel emphasizes the following features:

• Correctness. Bazel builds are designed to always produce correct output, period. If two users invoke the same build at the same commit with the same Bazel flags on different machines, they will see identical results. Incremental builds are as reliably correct as clean builds, rendering the latter essentially unnecessary.
• Performance. Builds are designed to execute as fast as intrinsically possible given the resources available to them. Tasks are as parallelizable as their dependency chains allow. Unnecessary work is never executed (i.e. “up-to-date” tasks are always skipped). Work can naturally be farmed out to remote executors to overcome local machine limits.
• Reproducibility. Any instance of a build can be faithfully reproduced in any environment. For example, if a bug report says version X of software Y fails in production environment Z, a developer can faithfully recreate it on their own machine with confidence that they’re debugging the same thing.

Answer 2

As article links tend to die, here is a summary of the Gradle Team's views on Bazel (most are directly lifted from the article, which was published in March 2015):

It was designed to solve a problem unique to Google; a massive monolithic codebase (hundreds of millions of LOC).

The parallelisation advantage Bazel currently provides will be matched by "our upcoming new configuration and component model" (bear in mind the article date here).

Bazel does not have a high level declarative build language that makes the build easy to use for developers. At Google this can be compensated with a specialized service team that owns the build tool.

Bazel is not built for extensibility (although the Bazel development team have since countered this with assurances that they are working on extensibility).

Speed is optimised around the idea that all transitive dependencies are stored in one big repo; all libraries and tools are checked in to this central repository. Most Enterprises have more distributed dependency management requirements.

Bazel is *nix only, it does not run on Windows. This eliminates a large number of potential Enterprises.

No plugin ecosystem.