A Domain-Specific Language (DSL) is a language tailor-made for a specific purpose. Instead of being a jack-of-all-trades, a DSL is a master-of-one, designed to fit the needs of a particular domain or industry. It’s a language that speaks _your_ language.
As of April 2023, Google announced that Kotlin DSL has become the default language for build scripts. The key is unifying all aspects of Android development with the Kotlin language.
## What are some differences?
Groovy strings are single quoted while Kotlin strings are double quoted.
In Groovy you can omit parentheses. Kotlin requires them.
In Groovy you can omit the equals sign in a lot of places.
Kotlin DSL is type-safe--you'll know if you have errors at compile time instead of runtime.
### My thoughts
In my opinion, Kotlin files are more readable. There's less whitespace in the middle of code. Explicit assignments using the equals sign are more familiar to the developer.
### Let’s look at some code examples!
`versionName '1.0'` is less readable than `versionName = "1.0"`
-- CODE line-numbers language-kotlin --
<!--
plugins {
id 'com.android.application'
}
-->
is less readable than
-- CODE line-numbers language-kotlin --
<!--
plugins {
id("com.android.application")
}
-->
## How do I migrate?
Android Developer Documentation
## How to manage dependencies?
This will be far from exhaustive!
In the Groovy world, one convention was to put all dependency version numbers and library string references in the project-level `build.gradle` file.
-- CODE line-numbers language- --
<!--
buildscript {
ext.versions = [
'dagger': '2.44.2'
]
ext.deps = [
'dagger': "com.google.dagger:dagger:${versions.dagger}"
]
}
-->
and then in module build.gradle files you can reference the dependency:
-- CODE line-numbers language- --
<!--
api deps.dagger
-->
### Version Catalogs
In the Kotlin world a common pattern is to use a `libs.versions.toml` file.
Android Developer Documentation
When you need to use a dependency you can reference it via:
`implementation(libs.core.ktx)`
One bit of "magic" is that if a library key string in your `libs.versions.toml` is named `lifecycle-runtime-ktx` it is referenced with periods replacing the dashes
`implementation(libs.lifecycle.runtime.ktx)`
I am not a fan of such magic.
When writing string keys the developer is often left to decide if they prefer camelCase, PascalCase, snake_case, or other.
In this scenario, you don’t know the implications of using dashes (or not) until you need to access the key value (AND, after a compilation to boot!). I’d rather the key be accessed exactly as it’s written by the developer.
### Bill of Materials
Another great tool for managing dependencies is utilizing Bill of Materials (BOMs), whether it's the Compose BOM that is built for us, or a BOM we create.
### 3rd Party Plugin
The Autonomous Apps Dependency Analysis Plugin is another heavily utilized tool for managing dependencies.
## Summary
Any differences in ease of learning, writing, reading, and using Groovy DSL compared to Kotlin DSL are negligible. Groovy _feels_ like a spoken and written language, while Kotlin _feels_ like a programming language. This might flatten the initial learning curve to learning Groovy, but needs too much _magic_ during compilation.
The value of developers using Kotlin EVERYWHERE when writing an Android app is large (e.g. Kotlin for views instead of XML, Kotlin for build files instead of Groovy, Kotlin for business logic instead of Java).
Kotlin starts to inch ahead and then run ahead when considering tooling, support, type-safety, and interoperability.
Migration **may not be helpful** if you have a giant legacy codebase of Groovy DSL Gradle build scripts.
**If starting a codebase from scratch**, Kotlin DSL should be the easy choice for your Gradle build files.
