Yes it's complex, yes the learning curve is basically a cliff (you either understand Gradle or you don't) and yes it can be slow.
But on the positive side:
I use the Kotlin DSL and the majority of my new projects are Kotlin also. As a result I now have a single language in use and no need to switch contexts. Type safe, null safe DSL for build configuration that also happens to be the same language I want to write my project in anyway? Yes please. It's basically Ruby Rake but better in this regard.
Potentially contentious point but I love being able to extend Gradle on a per-project basis with buildSrc plugins. This allows me to handle more complex tasks in a way that abstracts that complexity from the members of my team that don't necessarily have the same level of time invested in Gradle.
I like that it downloads itself via wrapper script. My projects only have one local dependency, a recent JDK. The build system downloads itself, then downloads all the project dependencies. This makes it easy for non-JVM members of my company to check the project out, make a small change and build the project without learning 5 other tools. cough Javascript cough.
I like that it's versioned per project when using the wrapper. I don't need to worry about some sort of runtime or package manager switcher like you would in Python/Ruby/Javascript land.
Don't get me wrong, Gradle is a long lived project with lots of skeletons in the closet but overall I think it's a very pragmatic tool for small projects all the way up to mid-sized monorepos. There does come a point when you will want to look at Buck or Bazel but most teams will never reach this point.
> I like that it downloads itself via wrapper script.
While I also use and enjoy Gradle, this is IMO its biggest weakness. We've all seen the recent supply-chain attacks, and ~everyone's infra is at risk here. There isn't even anything similar to Javascript's subresource integrity!
I'm sure that the people hosting Gradle are very cautious, but it only takes one slip-up...
As someone who has regrettable know about Gradle long enough to remember when someone actually thought Groovy might be "the future", the idea that they might support a different off-the-shelf syntax had never occurred to me... OMG you have made me so excited to try escaping.
How are you finding build/packaging times with gradle + kts building a kotlin project?
Gradle can be impressively fast (i’d hate to use a gradle build without the distributed build cache feature these days, what a difference), it can be reasonably easy to identify slow parts of a build (digging through build scans isn’t too hard). When it comes to extending it, groovy is actually pretty comfortable for making little doo-dads to assemble some shell scripts from templates, or populate an h2 with some build metrics, or whatever you need, but all in all i think i’m over gradle.
The speed is hard to keep on point, requires constant babysitting in a medium or large team and the learning curve really requires a reasonable working knowledge of groovy first (or kotlin - i haven't used the kts facilities) and a lot of java developers just aren’t interested in learning properly so they hack something in which leads to band aids that get hairy easily.
Speed is fine, in the larger monorepo projects I have worked on implementing plugins using the worker architcture and paying attention to parallelism by splitting things into sub-projects appropriately always kept build time reasonable.
You are correct that the biggest problem is that many people treat it as a distraction/unimportant part of their workflow and then wonder why things go badly.
As the most senior member on most teams I am on I take it on myself to take charge of the builds, CI and other tooling to ensure this doesn't happen and all engineers are productive. Unfortunately that isn't a solution for everyone but IMO it's how it should be, you make yourself a 10x engineer by magnifying the performance of your other team members.
To provide a counter-point I love Gradle.
Yes it's complex, yes the learning curve is basically a cliff (you either understand Gradle or you don't) and yes it can be slow.
But on the positive side:
I use the Kotlin DSL and the majority of my new projects are Kotlin also. As a result I now have a single language in use and no need to switch contexts. Type safe, null safe DSL for build configuration that also happens to be the same language I want to write my project in anyway? Yes please. It's basically Ruby Rake but better in this regard.
Potentially contentious point but I love being able to extend Gradle on a per-project basis with buildSrc plugins. This allows me to handle more complex tasks in a way that abstracts that complexity from the members of my team that don't necessarily have the same level of time invested in Gradle.
I like that it downloads itself via wrapper script. My projects only have one local dependency, a recent JDK. The build system downloads itself, then downloads all the project dependencies. This makes it easy for non-JVM members of my company to check the project out, make a small change and build the project without learning 5 other tools. cough Javascript cough.
I like that it's versioned per project when using the wrapper. I don't need to worry about some sort of runtime or package manager switcher like you would in Python/Ruby/Javascript land.
Don't get me wrong, Gradle is a long lived project with lots of skeletons in the closet but overall I think it's a very pragmatic tool for small projects all the way up to mid-sized monorepos. There does come a point when you will want to look at Buck or Bazel but most teams will never reach this point.