This message was deleted.

Source https://twitter.com/JakeWharton/status/1550108425752907776

workers allow for controlled parallel execution

As in running gradle with --parallel?

the left-hand side is wrong anyway since that runs at configuration time

right it'd need at least a doLast or something

Yep, other tasks could run in parallel, as long as they don't need the outputs of this task. https://docs.gradle.org/current/userguide/custom_tasks.html#worker_api:~:text=Once%20all%20of,begin%20executing%20immediately.

But that has nothing to do with

--parallel

, that is just for running tasks from different decoupled projects in parallel. The worker api parallelity is always on unless maybe you restrict it with

--max-workers

.

right,

--parallel

is about running tasks from different projects in parallel. the worker API is about running tasks from the same project to run at the same time. The need of the worker API will be reduced quite a bit with configuration caching (it will only be useful when you want to run several workers for a single task)

Reminds me of this idea of having an IDL which generates all the boilerplate for you...

The need of the worker API will be reduced quite a bit with configuration caching (it will only be useful when you want to run several workers for a single task)

Probably, yeah. But most people probably don't use the worker api for each and every tiny thing anyway, but only if they do long-running things or parallelizable tasks on multiple files.

Agreed most tasks don't need the worker API

using it to write a string to a file as in this example is complete overkill, I think we all agree

Right. In the android plugin we have a lot of usages of the worker APIs mostly for single worker tasks. I'm looking forward to simplifying them (Jake has a point on this, it's quite painful). We also do have a lot of simpler tasks where we don't use it because it's not worth it

the tweet is funny nonetheless. Another funny thing is that basically the initial version is what Maven does. It doesn't f* care about any input/output/incrementalism so it's much simpler to write.

Sadly, there are quite a few people who don't care and just want to write the left part only 😕

Gradle only makes it more complex because it has higher modeling, which makes it inherently better. Not easier for plugin authors, but better 🙂

Yes, except that it's not just "plugin authors". We see a lot of random users who don't understand anything try to make a custom task for one tiny feature they need, and they most definitively do the left side, because they don't know better (And in most cases don't want to have to learn mode).

It's totally ok to write the left part (if it is fixed to use

doLast

or

doFirst

) as long as you don't care about performance and correctness and anyway inherited the habit to always call the

clean

task along. 🙂

I wish Gradle both made it impossible to do the left side (so that you don't shoot yourself in the foot), and made it easier to do the right side

I spent a couple hours today showing a colleague of mine how to move from a left "spike" in a build script to a proper plugin (right, but without worker API). He was baffled how clean the final solution was 🙂

It's totally ok to write the left part (if it is fixed to use

doLast

or

doFirst

) as long as you don't care about performance and correctness and anyway inherited the habit to always call the

clean

task along. 🙂

but then they come back to us (and Gradle) and complain their builds are slow...

the right side is already much easier than it used to be. Automatic code generation for

Property<String>

is a huge win.

Then that's the point where they have enough motivation to do it the right way 😄

Sadly the current narrative is "Gradle is slow", not "my random customizations" (or "my compilers", looking at you Kotlin...) are slow.

you forgot "I hate build tools" 🙂

all build tools suck, gradle just sucks less at several ways I care about

Kotlin is not slow. It is a bit slower than Groovy in some cases and it is a bit faster than Groovy in other cases. (and yes, I'm talking about Gradle build scripts, not about the languages in general)

Kotlin compilation is order of magnitudes slower than Groovy. Fun fact: when I joined Gradle, my first task was to optimize Groovy scripts compile times. It became blazing fast. Then we had Kotlin DSL and it was like 10x slower but nobody cared (almost). Sad.

The Kotlin compiler is slow (work is being done to fix it, though it'll never be as fast as javac). Now regarding KTS, I have a project where groovy script compilation takes 90s and the same version with KTS takes 10min. (this is with ~3,400 build files)

o_O

parallel script compilation would be nice, someday…

yeah Paul told that to me then I did the test and was a bit shocked. I'm going to send them the projects for them to play with them

Yes, please do 🙂

until you edit a build file, but otherwise yes 🙂

Hopefully most time you edit code, not build and even if you edit a build file hopefully only that one is recompiled and not all 3400 that are unchanged 🙂

right but then you still need to rebuild the task graph and that's slow too 🙂

Always 🙂

every large build system has that problem. google3 blaze bazel already had to deal with the full task graph being too large to fit into memory years ago, iirc

@melix wrt code generation for Property<String>, does that mean its better to use abstract inputs/outputs? Would you provide defaults in the constructor then?

Actually, I learned that in an idiomatic structure, the extensions and tasks should be unopinionated and thus do not have default values, and the according plugin that registers specific tasks adds opinion by wiring together extension and task properties and setting default values.

Ah so drop all the defaults in the tasks.register block?

For example, yes

for tasks that usually are only created once per project, i will sometimes put a companion object in the Task class (kotlin) with a JvmStatic method that takes a project, and registers the task, then applies all the default opinions, just to make the plugin code simpler for the default case. and then you can always just register the task the regular way if you want one with no opinions