is anyone using Buck (<https://buckbuild.com/>) in...

# android

[kkozmic]

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

[mg6maciej]

I bet Facebook does 😉

[bulwinkel]

uber does

[kkozmic]

do they use Kotlin?

[bulwinkel]

not in production

[bulwinkel]

they discussed it in an episode of http://fragmentedpodcast.com/

[bulwinkel]

you should watch this talk

[bulwinkel]

https://www.youtube.com/watch?v=BKRK4SvMtRk▾

[kkozmic]

thanks

[kkozmic]

so everyone here is happy with just using Gradle?

[mg6maciej]

I'm not happy. I want ANT!

[mg6maciej]

It took 1-2 seconds to build and run on a device a medium sized app in the old days.

[kkozmic]

not a huge fan of XML but I see your point

[mg6maciej]

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

[kkozmic]

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

[kkozmic]

as for the compilation time, Kotlin has much more smarts than Java so that's kind of expected. Even if there's certainly still room for speed increases

[kkozmic]

@bulwinkel thanks for that YT link. Benchmarks benchmarks so YMMV but good to see they have some ambitious performance goals in mind

[kirillrakhman]

@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.

[bulwinkel]

I am glad buck is making gradle work so hard

[bulwinkel]

to improve their build times

[bulwinkel]

with gradle 3.5 my average build time is now < 10 secs in a reasonably sized project with 4 modules

[spierce7]

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

[spierce7]

I'd recommend sticking it out with Gradle a little while longer, and I think you'll find things are better with the Android Plugin 2.5.

[kkozmic]

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)

[kkozmic]

Most other build systems take minutes to grasp and really understand. With Gradle I feel like I'm just doing Cargo Cult, copy/pasting code from documentation/StackOverflow and hoping it works

[spierce7]

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.

[kevinmost]

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.

[guylandro]

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...

[johnl]

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

[johnl]

Nobody could force me to use maven in a work environment anymore than they could force me to use windows

[johnl]

There is simply no reasonable discussion to be had about using maven the tool itself has been debunked as one of the worst things to happen to java, except for src/main/java and the repo format

[kkozmic]

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:

[kkozmic]

1. Is Gradle the best tool, both now and for the foreseeable future

[kkozmic]

2. Is Gradle hard to understand, basically a magical black box (plus the added questions of performance which seems to be getting worked on with some encouraging results)

[kkozmic]

When I asked the original question it was to assess 1 as a result of my frustration with 2. Even if the answer to 1 is a resounding yes, it still leaves question 2 unsolved

[bulwinkel]

have you had a look at gradle script kotlin yet?

[bulwinkel]

it definitely tackles the “magical black box” scenario