Most build systems have their idiosyncrasies. I do a lot of Kotlin (on server, multi platform, and browser), so I've been an early adopter for the kts dialect.

Most build systems have their idiosyncrasies. I do a lot of Kotlin (on server, multi platform, and browser), so I've been an early adopter for the kts dialect. I've used maven and ant in the past on the jvm. And off the jvm things like make, webpack, and other things. And of course lots of configuration language tools (puppet, chef, ansible) as well as things like travis, jenkins, and Github actions. So, I know my tools. And occasionally love to hate them. Most of these tools have stuff they are good at and stuff that while they can technically can do they just aren't the best tool for. Things I don't like about gradle: - the whole (kotlin scripting) kts vs. groovy split. IMHO groovy makes things harder at this point and more poorly discoverable. And because the kotlin scripting part has to be sort of compatible with the groovy part you are left with auto completion that works poorly because of the multiple unnecessary levels of indirection that comes in via the groovy centric internals. This has been improving slowly over the years. At least for new projects, kts is now the default (in Android studio). - all the "maybe this will work" performance hacks that the gradle people built into their tool over the years. You get lots of complexity from layers of caching, daemons, half working offline modes, etc. They work a little bit but the multiple layers of hacks, outdated feature flags, etc. are annoying. - regular compatibility breaking changes that mean suddenly your build no longer works on a major version change. "we changed our mind, again, about how stuff is supposed to work" and please be fixing all your build files. The how bit is typically left as a hunt through bad documentation. - the maze of misdirection that is the documentation and the collective body of unhelpful stackoverflow posts and other online articles. Which thanks to regular compatibility breaking changes and the switch to kts tends to be groovy centric and hopelessly outdated. A lot of the "solutions" you find either don't work at all due to this or needs to be translated. Anything over two years old is probably wrong at this point. It's that bad. On a positive note, it does work once you get it dialed in. And I tend to not mess with my build files too much. If it looks like a shell script, I'm not even going to attempt doing it from gradle. I'll automate via github actions rather than gradle. Just easier. And while kts is a PITA to deal with in intellij (it freaks out regularly over phantom compile errors for no good reason whatsoever until you turn it off and on again), having auto completion helps. And being able to use regular kotlin to do stuff is also helpful. But doing simple things is still way too hard. Mostly I stick with gradle because it is the path of the least resistance. It's the thing that is supported by world + dog, probably the most likely thing to be documented, and others sort of expect it at this point. Everything else is more work to figure out and set up.