A modern programming language that makes developers happier.

kotlinlang

Is there a reason for having these different different ways to get a task, and any reason why you might use one or the other? `tasks["foo"]`, `tasks.named("foo").get()`, `tasks.getByName("foo")`

To addition to Trevor's comment, first `get` operator syntax not only eager, but also cannot return typed task, there are typed version for named and getByName

I think one of the main reason is that Gradle was written in Groovy primarily and there the differences were hidden within the dynamic nature of the language. If you want to go with a build-with-Kotlin-in-mind build tool (even if it’s less known, which means way fewer plugins), check out Kobalt <http://beust.com/kobalt/home/index.html>

&gt; I think one of the main reason is that Gradle was written in Groovy
But Gradle is not written in Groovy, it written mostly in Java (at least core part), DSL on Groovy

but the configuration part was with Groovy in mind and there you have all those automatic conversion, e.g. a Provider&lt;X&gt; is pretty much X, so the “.get()” disappears.

I agree that there is too many dynamic magic in Gradle, but it  shifted a lot now to be more static with Kotlin DSL

&gt; Provider&lt;X&gt; is pretty much X, so the “.get()” disappears
Which is also bad to use, because it cause eager configuration and not needed almost never and shouldn’t be used in 98% cases, so in case of task it’s actually good, that there is sign of eager configuration like .get()

interesting, i didn’t think about that before :+1: So yes, some of the stuff that was kind of elegant/magical in GroovyDSL is more verbose and suddenly not as nice in KotlinDSL (on the code appearance level, of course I wouldn’t want to trade in the benefits of static typing). If it wasn’t for Gradle’s rich plugin ecosystem, I’d move straight to Kobalt though. Alas, a rich plugin ecosystem is a hell of an advantage :laughing: