is anyone using Buck (https://buckbuild.com/) instead of Gradle for their build in real production non-trivial apps?

I bet Facebook does 😉

uber does

do they use Kotlin?

not in production

thanks

I'm not happy. I want ANT!

not a huge fan of XML but I see your point

Kotlin doesn't help either with TDD. It compiles slower than Java. I'm not complaining 😉

I'm equally annoyed with Gradle by the poor performance as I am by how opaque it is, which makes it hard to diagnose and fix issues

@mg6maciej I think the reason, deploying an app in the Eclipse days was fast, is because the Android plugin used the Eclipse compiler which is incremental and ran everytime you saved a file. When it was time to deploy, the plugin only had to dex und to package.

I am glad buck is making gradle work so hard

I'd be hesitant to move away from Gradle for a few reasons: 1. It's the default supported build system. There are a lot of really useful services that require gradle plugins to use (i.e. Crashlytics). You could go off on your own and support this through buck, but it'd be painful. 2. Gradle has actually gotten it's act together. There is a nominal difference in compilation speed between Gradle and Buck (or Bazel). Performance improvements have been a huge focus in the past few release of 3.x. With Gradle 3.5, they've even added a proper build cache (and even a distributed cache like buck!). The reason why your Android builds are slow right now isn't because of Gradle, but rather because the Android Gradle Plugin is slow, and the Android Gradle build tasks, don't yet take advantage of all the new fast awesome features from Gradle yet (i.e. none of the Android build tasks can be cached yet). The Android tooling team, and Gradle have been working closely to resolve this for Android plugin version 2.5 (which I'm REALLY looking forward too). You can read about it, and see some early benchmark numbers here: http://tools.android.com/tech-docs/new-build-system/2-5-alpha-gradle-plugin

That's all true @spierce7 from the ecosystem and performance perspective. And it's definitely one of the main issues I've had with it. There's still the other one, being - Gradle is just such a massive black box and I feel like it's by at least an order of magnitude the most complex build system I've ever used (and I've used many)

That's interesting to hear. I feel strongly that the flexibility of Gradle has spoiled me, and it makes me dislike it when I have to work with other build systems that don't offer the kind of flexibility that Gradle offers. The Android plugin actually formalizes some of that flexibility and allows it's barrier to access even simpler. i.e. Android flavors are amazing in Gradle.

The main reason that Gradle feels like you're cargo-culting is because of Groovy and its dismal IDE support. GSK (gradle-script-kotlin) should make this way better. To be honest, the feeling of not understanding my build system is one of the reasons I really dislike Maven. At least I understand programming, so I can sort of feel my way around Groovy. Maven is just a confusing mess of arbitrary config files to me.

Maven actually made more senses to me back in the day (i.e. not anymore). Nowadays just like @kkozmic, I paste things randomly to build.gradle and hopes that it works. A good understanding of the build system will definitely take me a long way, but still, my team also have people who maintain the gradle files...

Gradle is amazing (even tho all build tools kind of suck) NOT using gradle is an antipattern. When people ask me why I use gradle I simply say because I was paying attention 5 years ago

Some good points here. I can see we've got two issues being debated here, both at the same time, both related but distinctly different:

have you had a look at gradle script kotlin yet?