So I went through this stage too but I stuck it out to pass through to the other side. Mostly because the options weren't any better.
Gradle's main problem is that it doesn't have a learning curve, it has a learning cliff. You either understand it or you don't and that is terrible for adoption and for people trying to get it like this fellow.
What lies beyond this stage is understanding that these things -are- actually complex for a reason. Attempting to create something simpler just for your "simple" use case eventually requires you to add more stuff to do some new thing and before you know it you have a shitty version of Gradle instead of normal Gradle with some custom plugins/tasks/whatever you happen to need.
That said I'm in the process of going deep on Bazel because Gradle still falls short of the mark for me. Bazel has more of an actual learning curve, it's peak complexity is lower than Gradle (though mostly because it's offloaded that complexity into rulesets).
The reality is that these build systems are hard because they are designed to solve very hard problems when you are building programs with lots of artefacts at big scale where very fine grained caching isn't just nice to have but imperative in order to actually do builds at a reasonable cadence.
Appreciation of these systems is tightly coupled to -actually- having those problems. If you don't have those problems you probably don't get why these things are so complicated/baroque/alien/whatever they may seem to you.
In Gradle's case you can generally build a bunch of JVM code without really understanding Gradle. I consider this to be a bit of a trap but I get -why- it's like this which is that it would simply have no adoption if everyone had to understand the phases, source sets, etc but I still don't like copy/paste builds all the same.
Bazel is both slightly better and slightly worse in this regard. You need to understand some more Bazel concepts to build anything at all - which I consider a good thing, understanding vs copy-paste is good in my book. However that understanding is a bit of an illusion once you realise you need something with a modicum of more complexity.
Soon you will open up a ruleset and realise that for instance the inbuilt rules_java is actually lugging around this JavaInfo thing and rules that are "java aware" are doing things with this rather than "just artefacts" as your simple understanding was let you to believe etc.
Most programmers don't give build systems that respect they deserve. They want them to just work and be out of their way, mostly because they don't care how their artefacts get built. I think this is both wrong and sad but I also don't see it changing, too many incentives to not care as long as it builds. Meaning that understanding of real build systems is concentrated on a small number of individuals at a few places big enough to need them.
Gradle's main problem is that it doesn't have a learning curve, it has a learning cliff. You either understand it or you don't and that is terrible for adoption and for people trying to get it like this fellow.
What lies beyond this stage is understanding that these things -are- actually complex for a reason. Attempting to create something simpler just for your "simple" use case eventually requires you to add more stuff to do some new thing and before you know it you have a shitty version of Gradle instead of normal Gradle with some custom plugins/tasks/whatever you happen to need.
That said I'm in the process of going deep on Bazel because Gradle still falls short of the mark for me. Bazel has more of an actual learning curve, it's peak complexity is lower than Gradle (though mostly because it's offloaded that complexity into rulesets).
The reality is that these build systems are hard because they are designed to solve very hard problems when you are building programs with lots of artefacts at big scale where very fine grained caching isn't just nice to have but imperative in order to actually do builds at a reasonable cadence.
Appreciation of these systems is tightly coupled to -actually- having those problems. If you don't have those problems you probably don't get why these things are so complicated/baroque/alien/whatever they may seem to you.
In Gradle's case you can generally build a bunch of JVM code without really understanding Gradle. I consider this to be a bit of a trap but I get -why- it's like this which is that it would simply have no adoption if everyone had to understand the phases, source sets, etc but I still don't like copy/paste builds all the same.
Bazel is both slightly better and slightly worse in this regard. You need to understand some more Bazel concepts to build anything at all - which I consider a good thing, understanding vs copy-paste is good in my book. However that understanding is a bit of an illusion once you realise you need something with a modicum of more complexity.
Soon you will open up a ruleset and realise that for instance the inbuilt rules_java is actually lugging around this JavaInfo thing and rules that are "java aware" are doing things with this rather than "just artefacts" as your simple understanding was let you to believe etc.
Most programmers don't give build systems that respect they deserve. They want them to just work and be out of their way, mostly because they don't care how their artefacts get built. I think this is both wrong and sad but I also don't see it changing, too many incentives to not care as long as it builds. Meaning that understanding of real build systems is concentrated on a small number of individuals at a few places big enough to need them.