I asked for the best or easiest tooling for Java on Twitter, as someone who knows the language and has a few use-cases but never set up a project from scratch before. The consensus there was Gradle is the easiest to get going, but perhaps Maven is more understandable.
A few people suggested Bazel, but the “getting started” for Bazel is a zillion word tutorial and there’s little to no help from the Bazel command line tooling to understand how it’s supposed to work. I poked around the docs site a bit and overall came away with the impression that Bazel is something you use if you worked at Google or with a derivative/clone system and the main way to be productive with it is to apprentice under a Bazel Practitioner and no one learns it “from scratch”.
Compared to Gradle which provides a gradle init I guess this tool is mostly for teams that outgrew some other tool and can invest years adopting it?
I’m curious what your (OP or anyone) experience is like with similar tools, how you came to have a build set up, or if there’s a happy alternative that works like go build, go test for Java. From the language i think it should be totally possible to have a zero-configuration tool like go if you assume some conventions, but maybe I’m too much of a noob to understand.
OP here. The reason I got into Bazel is two-fold: one, because I had always had interest in and had been looking for a “better” declarative build system (and even tried to write my own eons ago!); and, two, because (yes) I did work at Google for a long time and got to experience and “grow with” Blaze. I did appreciate it being open-sourced at some point, but also saw that it wasn’t really a great fit for external projects at the time, and it’s still lacking in some areas.
I agree the docs are problematic. There is a big gap between “here is a trivial tutorial” to the “here is the reference manual”. This is something that I’d like to work on in the near future, because this surfaces as a big problem at work when we onboard new hires. I’m not sure it’ll be “externalizable” in any way though, because to make the material easy to follow, it’ll have to be scoped to our codebase and the very specific needs of our engineers… but it’s true this must improve.
Personally, I’d say that if you are working on a project that is written in exclusively one language, you are likely better off sticking with the defacto tooling for that language. This is specially true if you do Go or Rust, because it’s hard to beat their tooling in simplicity and performance. Now, once you start putting together components written in different languages, that’s where Bazel starts to become useful, because instead of gluing together things with crappy shell scripts, you can orchestrate the full build with Bazel. Similarly when your code grows past a certain size and you need to scale the build out of one machine.
So yeah, in a sense, you shouldn’t need to reach for Bazel until you get to certain levels of complexity or scale. I find this sad though, because I’d prefer if a tool like this was usable in even the smallest projects, but the current complexity behind Bazel and the sheer size of its implementation make it impractical for these scenarios.
As for the “zero configuration”, that’s what some folks would like to get to with the idea of “no build files” that I mentioned in the notes. I’m not sure where that’ll go though.
because instead of gluing together things with crappy shell scripts, you can orchestrate the full build with Bazel
I feel like there is some space where it makes sense to write genuinely good shell scripts (or tooling in some other language) rather than switching to Bazel or using ‘crappy shell scripts.’ Bazel definitely has some good ideas that one won’t get from an imperative system, but it comes at a pretty high cost; in some cases the benefits are arguably not worth it.
Wow, great writeup, thanks. “Detailed synthesis of conference” is a skill I do not have.
I asked for the best or easiest tooling for Java on Twitter, as someone who knows the language and has a few use-cases but never set up a project from scratch before. The consensus there was Gradle is the easiest to get going, but perhaps Maven is more understandable.
A few people suggested Bazel, but the “getting started” for Bazel is a zillion word tutorial and there’s little to no help from the Bazel command line tooling to understand how it’s supposed to work. I poked around the docs site a bit and overall came away with the impression that Bazel is something you use if you worked at Google or with a derivative/clone system and the main way to be productive with it is to apprentice under a Bazel Practitioner and no one learns it “from scratch”.
Compared to Gradle which provides a
gradle initI guess this tool is mostly for teams that outgrew some other tool and can invest years adopting it?I’m curious what your (OP or anyone) experience is like with similar tools, how you came to have a build set up, or if there’s a happy alternative that works like
go build,go testfor Java. From the language i think it should be totally possible to have a zero-configuration tool likegoif you assume some conventions, but maybe I’m too much of a noob to understand.OP here. The reason I got into Bazel is two-fold: one, because I had always had interest in and had been looking for a “better” declarative build system (and even tried to write my own eons ago!); and, two, because (yes) I did work at Google for a long time and got to experience and “grow with” Blaze. I did appreciate it being open-sourced at some point, but also saw that it wasn’t really a great fit for external projects at the time, and it’s still lacking in some areas.
I agree the docs are problematic. There is a big gap between “here is a trivial tutorial” to the “here is the reference manual”. This is something that I’d like to work on in the near future, because this surfaces as a big problem at work when we onboard new hires. I’m not sure it’ll be “externalizable” in any way though, because to make the material easy to follow, it’ll have to be scoped to our codebase and the very specific needs of our engineers… but it’s true this must improve.
Personally, I’d say that if you are working on a project that is written in exclusively one language, you are likely better off sticking with the defacto tooling for that language. This is specially true if you do Go or Rust, because it’s hard to beat their tooling in simplicity and performance. Now, once you start putting together components written in different languages, that’s where Bazel starts to become useful, because instead of gluing together things with crappy shell scripts, you can orchestrate the full build with Bazel. Similarly when your code grows past a certain size and you need to scale the build out of one machine.
So yeah, in a sense, you shouldn’t need to reach for Bazel until you get to certain levels of complexity or scale. I find this sad though, because I’d prefer if a tool like this was usable in even the smallest projects, but the current complexity behind Bazel and the sheer size of its implementation make it impractical for these scenarios.
As for the “zero configuration”, that’s what some folks would like to get to with the idea of “no build files” that I mentioned in the notes. I’m not sure where that’ll go though.
I feel like there is some space where it makes sense to write genuinely good shell scripts (or tooling in some other language) rather than switching to Bazel or using ‘crappy shell scripts.’ Bazel definitely has some good ideas that one won’t get from an imperative system, but it comes at a pretty high cost; in some cases the benefits are arguably not worth it.