←back to thread

392 points mfiguiere | 4 comments | | HN request time: 0.539s | source
1. candiddevmike ◴[] No.35471951[source]
For folks that are using these kinds of tools, any regrets? How much more complexity do they add vs make or shell scripts?
replies(3): >>35472581 #>>35475058 #>>35475691 #
2. numbsafari ◴[] No.35472581[source]
Speaking of the “tools” genrically, they are totally worth it because of their ability to aggressively cache and parallelize, but also because you end up with more declarative definitions of common build targets in a way that is more or less type safe. I personally think that makes these kinds of tools a win over make. Beyond that, they make it trivial to implement repeatable builds that run build steps in “hermetic” sandboxes. You can do all that with make, but you are abusing the hell out of the tool to get there, and it will look foreign to anyone familiar with using make “the traditional way”.

That said, bazel’s set of prepublished rules, reliance on the jdk, etc, make it not worth the burden, imo/e.

I think less ambitious, but similar tools are where it’s at. We use please for this reason, and are generally quite happy with how it balances between pragmatism and theory.

In any event, having your build tool be a single binary is a major win. I’d rather use make than anything written in python or Java just because I don’t have to worry about the overhead that comes with those other tools and their “ecosystems”.

3. optymizer ◴[] No.35475058[source]
I've used Buck at Meta for years and while it is technically impressive and does an excellent job with speed, remote compilation and caching, I am not a fan of all of the undocumented, magic rules used all over the place in BUCK and .bzl files.

I've yet to try BUCK on small projects though - I personally default to Makefiles in that case.

On thing I definitely wouldn't use it is for Android development. The Android Studio integration is much worse than gradle's and adding external dependencies means you have to make BUCK modules for each one.

I would however use it for large-scale projects or projects with more than a dozen developers.

4. krschultz ◴[] No.35475691[source]
IMO one of the nice things about Buck or Bazel is that once you learn it, switching languages doesn't require you to learn a completely new tool. Obviously the cost of learning it the first time is high and if you are used to one ecosystem may not be worth it. But I'm now on my 3rd different ecosystem that uses Buck/Bazel (Android, iOS, C++) and it's nice to not worry at all about the underlying tools.