Dev Easy Notes

🎩Kts

На фоне всех этих претензий к Groovy, ребята из JetBrains решили, что стоит упростить всем жизнь и заменить неудобный и неочевидный Groovy на всеми любимый Kotlin. Kotlin благодаря своему синтаксису практически один в один позволяет писать скрипты в том же стиле, что и на Groovy. При этом у нас есть статическая типизация и более адекватная поддержка со стороны IDE.

С одной стороны это круто, теперь все действительно очевиднее, так как сложно на Kotlin написать что-то неожиданное. Однако, Kotlin ни разу не скриптовый язык и за все ништяки мы платим тем, что теперь скрипты перед выполнением компилируются. 

Если у вас мелкий проект, разницы вы не заметите. Однако при росте проекта у вас начнутся проблемы. Смотрим на табличку, тест проводили на довольно свежей версии Gradle. Тут явно прослеживается проблема kts, при первом запуске он медленнее Groovy в 1.6 раз. Если конфигурация проекта занимает допустим 30 секунд, теперь будет занимать под 50. Разумеется билд кеш, спасает, однако при переключении с ветку на ветку…

Это все вытекает из фундаментального ограничения Gradle про которое я упоминал ранее. Gradle не умеет в инкрементальность конфигурации, из-за этого внедрение kts решает одну проблему, но создает другую. Разумеется статическая типизация намного круче, лучше интеграция с IDE, не нужно гадать типы. Однако чтобы это работало, билд система должна уметь рассчитывать изменения и запускать компиляцию только там, где это нужно. 
 
Отсюда выходит один интересный вывод, не нужно использовать kts для описания скриптов в модулях. Он хорош для написания конвенций, т.е для тех вещей, которые редко меняются или для плагинов. В обычных скриптах он не сильно много пользы приносит.

В итоге вот вам рецепт:
1️⃣ build.gradle лучше писать на groovy, в них нет и не должно быть никакой логики, а только перечисление плагинов, конвенций и зависимостей для конкретного модуля.

2️⃣ Общие конфигурации выносим в конвенции и их уже можно писать на kts. Они будут компилироваться только в одном месте, это уже не так сильно будет бить по времени конфигурации.

3️⃣ Если появляется какая-то сложная логика, это лучше выносить в плагины. Сам плагин можно и нужно писать на kotlin, его можно будет сделать бинарным и тогда он вообще не будет компилироваться.

P.S Сори за долгое отсутствие, просто был небольшой отпуск, не волнуйтесь на канал я не забил)

❤32👍15🤔2🤯1

www.tgoop.com/dev_easy_notes/197

2.23K viewsedited  Dec 1, 2022 at 09:02

🎩Kts

На фоне всех этих претензий к Groovy, ребята из JetBrains решили, что стоит упростить всем жизнь и заменить неудобный и неочевидный Groovy на всеми любимый Kotlin. Kotlin благодаря своему синтаксису практически один в один позволяет писать скрипты в том же стиле, что и на Groovy. При этом у нас есть статическая типизация и более адекватная поддержка со стороны IDE.

С одной стороны это круто, теперь все действительно очевиднее, так как сложно на Kotlin написать что-то неожиданное. Однако, Kotlin ни разу не скриптовый язык и за все ништяки мы платим тем, что теперь скрипты перед выполнением компилируются. 

Если у вас мелкий проект, разницы вы не заметите. Однако при росте проекта у вас начнутся проблемы. Смотрим на табличку, тест проводили на довольно свежей версии Gradle. Тут явно прослеживается проблема kts, при первом запуске он медленнее Groovy в 1.6 раз. Если конфигурация проекта занимает допустим 30 секунд, теперь будет занимать под 50. Разумеется билд кеш, спасает, однако при переключении с ветку на ветку…

Это все вытекает из фундаментального ограничения Gradle про которое я упоминал ранее. Gradle не умеет в инкрементальность конфигурации, из-за этого внедрение kts решает одну проблему, но создает другую. Разумеется статическая типизация намного круче, лучше интеграция с IDE, не нужно гадать типы. Однако чтобы это работало, билд система должна уметь рассчитывать изменения и запускать компиляцию только там, где это нужно. 
 
Отсюда выходит один интересный вывод, не нужно использовать kts для описания скриптов в модулях. Он хорош для написания конвенций, т.е для тех вещей, которые редко меняются или для плагинов. В обычных скриптах он не сильно много пользы приносит.

В итоге вот вам рецепт:
1️⃣ build.gradle лучше писать на groovy, в них нет и не должно быть никакой логики, а только перечисление плагинов, конвенций и зависимостей для конкретного модуля.

2️⃣ Общие конфигурации выносим в конвенции и их уже можно писать на kts. Они будут компилироваться только в одном месте, это уже не так сильно будет бить по времени конфигурации.

3️⃣ Если появляется какая-то сложная логика, это лучше выносить в плагины. Сам плагин можно и нужно писать на kotlin, его можно будет сделать бинарным и тогда он вообще не будет компилироваться.

P.S Сори за долгое отсутствие, просто был небольшой отпуск, не волнуйтесь на канал я не забил)

BY Dev Easy Notes