“At the same time, JetBrains is running an experiment with similar goals called Amper. One of our objectives is to leverage this experiment to benefit the development of Declarative Gradle and provide a great user experience for Kotlin and Kotlin Multiplatform. Therefore, in addition to the dedicated group focused on Declarative Gradle, we are working closely with the Amper team at JetBrains.”

Yup, that's the important part 🙂 . Thanks for highliting!

Thank you for sharing it!

Looks like Gradle is planning to use a subset of Kotlin and not yaml: https://mastodon.mbonnin.net/@melix@mastodon.xyz/111385961093799051

Worth quoting the Amper blog post here again:

In regards to using YAML, some of you may be wondering, why not Kotlin? While the decision on this markup language is not final, we do want to take a declarative approach. We believe that this not only allows for a more simplified configuration that is less error-prone, but it also helps us in terms of providing better tooling. And again, for the sake of sharing this experiment with you and validating ideas behind it, we’ve taken the simplest approach. Whether or not we’ll end up with a restrictive subset of Kotlin as the frontend language is yet to be decided. For now, our focus is on validating our ideas.

I think one big advantage of toml,cue-lang (or even yaml) is that it is super fast to evaluate, nothing to execute, nothing to compile. snappy builds without config caching.

Config caching includes more than "evaluating" the scripts. It also includes the calculation of the task graph and dependency resolution caching. Plus the isolation of tasks which allows for safe execution parallelism.

oh interesting that makes perfect sense.

We believe a declarative only restricted DSL will provide a huge performance boost compared to compiling Kotlin scripts, close to using a data format.

what does task isolation have to do with caching?

CC serializes all task inputs in order to cache the task graph and prevents tasks to access shared mutable state at execution time.

ok but a config based solution could just built that immutable graph at parse time and be as fast as config caching without a cache.

On a large build, the task graph calculation time is not negligeable.

I’m excited for amper because a lot of projects could just work with just a list of main deps a list of test deps and the main class. and a list of plugins like ktlint, and jacoco

Yes, that's the other part of Declarative Gradle, a higher level software definition for an easier configuration. That's also where there's more synergy between the two efforts.

looking forward to that, I will for sure try out both.