github linkedin email rss
Golang and the Next-Gen Build Tools
Apr 30, 2017
4 minutes read

The three general build systems from the big players. Bazel by Google, Pants by Twitter and Buck by Facebook, all attempt to allay the problems plaguing build system since time immemorial. They are all based on the internal build system from Google, Blaze, and as such, they are almost identical in features. They improve on the correctness, speed and modularity of the builds with features such as sandboxed builds, caching of targets, and namespacing of build modules. 

They enforce the correctness of the task definitions and its dependencies, and thereby allow the optimization of incremental builds by caching intermediate results. They have client-server implementations to allow significant speedup of build operations. They are extensible and configurable. 

So, how do they compare? Which one is best? Well, for starters, here’s a table of features:

Build Tool Ease of Installation Windows Support Go Support Other
Bazel Single script installer Beta
  • Beta:
  • - Rudimentary dependency management
  • - Bootstraps go tool
  • - Cgo
  • iOS, Android
  • C++, Java, Python
  • Rust
  • Javascript using Closure (3rd party support for NodeJS)
  • Docker
Pants Check-in-able runner script Nope
  • Good:
  • - Good-ish dependency management
  • - go-fmt (beta)
  • - Bootstraps go tool
  • iOS, Android
  • C++, Java, Python
  • Javascript through NodeJS
  • Rust
Buck
  • Mac
  • - Brew tap
  • Linux/Windows
  • - Build from source
Yes
  • Basic:
  • - No bootstrapping of go binary.
  • - No dependency management.
  • iOS, Android
  • C++, Java, Python
  • Haskell
  • Rust

Pants is the first of the three to be released as open source, and it shows, it is the one with the shiniest features. It has good dependency management, integration with the tools you’re probably using now and it is easy to setup whether it is on your workstation or remote build machines.

Next up is Bazel. It feels like an industrial grade tool, with a nice web page, lots of stars on its github page and Windows support. But it is still lagging in features compared to pants. The lack of good dependency management means you will be writing dependency files by hand. No support for coverage means you’ll have to run scripts on the side. The goals of the Bazel project are more geared towards big companies and not for small projects (which is to be expected of Google). Depending on what language your project is mainly written (say Python1) Bazel might not be ready for prime time, unless you’re already vendoring (copying) 3rd party code into your repository or if you’re willing to make the (non-trivial) change.

As for Buck, well, it is a tool more geared towards front-end and mobile development. And it looks like a really good tool if you work on that segment. But you’ll need to build it yourself if you want to use it on Linux, and that’s a show stopper for me (at least give me bootsrap script!). Really nice output and good support for Windows might make this your first choice. Do note that Buck is the youngest of the tools, perhaps it will take over the build system world?

Summary

If limiting our scope to projects using Go, Pants takes the cake. It’s documentation for Go is top notch, and it walks you through the whole process. They’re pretty responsive on their community channels, specially on slack. Trying up and coming features is as simple as changing the Pants version in the pants.ini file. And if you extend your considerations to other languages, you’d be more than satisfied with Python+Pip+PEX support, NodeJS+NPM, along with the usual C++ and Java.

Perhaps the best build tool will not remain the same one. Let’s hope that the open source model shared by the tools will enhance their improvement through the competition and sharing of features. But, whether it is Pants, Buck or Bazel, these Next-Gen build tools feel like the future even if you’re not following the monorepo structure in your organization. I keep wondering where the hype behind the next-gen build tools is, I would consider starting to use these tools, if only for the speedups in builds2. Now, if you add build correctness and code organization improvements to the mix…

What do you think?


Back to posts


comments powered by Disqus