В проекте Apache Groovy перестаёт участвовать один из ключевых участников сообщества, само имя которого у многих ассоциировалось с этим языком. Уходит Седрик Шампо, известный в первую очередь как автор статического компилятора Groovy.
Если рассмотреть причины ухода в том виде, как их формулирует сам Седрик, получается история о том, как Groovy-сообщество хотело лучшего, а в итоге ненамеренно сделало себе хуже. В самом сообществе, впрочем, есть другие трактовки произошедшего. В любом случае история может быть интересна и разработчикам из JVM-мира, и не только.
Чтобы понять произошедшее, надо зайти издалека. Язык Groovy, версия 1.0 которого вышла в 2007-м, стал претендентом на роль «лучшей Java»: он тоже был рассчитан на JVM, и при этом принёс ряд новых возможностей, полюбившихся разработчикам. Например, известный многим джавистам Барух jbaruch Садогурский в своё время писал на Хабре о том, как прекрасны AST transformations и как они улучшают жизнь при работе с Java.
Groovy проникал в разные области. Например, на нём основали DSL для билд-скриптов в Gradle, тем самым резко повысив заметность языка: самые разные джависты стали регулярно сталкиваться с ним в контексте сборки, что провоцировало дальнейший интерес к языку. Наблюдая такие события, легко было представить светлое будущее, в котором Groovy займёт непоколебимые позиции в лидерах JVM-языков.
Шли годы, и Groovy, с одной стороны, вполне использовался, с другой — не сказать чтобы захватил мир. А перспективы при этом были неопределёнными: например, с появлением Java 8 стала менее очевидна потребность в «лучшей джаве».
А затем начал стремительно набирать популярность Kotlin. Его создатели называют Groovy в числе тех языков, которыми вдохновлялись, так что в некоторых отношениях Kotlin напоминает Groovy. В принципе, это подтверждает, что в Groovy были приняты правильные решения: они зарекомендовали себя на практике, и другим захотелось перенимать их. Но часть Groovy-сообщества не порадовалась такой валидации идей, а увидела угрозу.
Ещё один JVM-язык (теперь уже не только JVM, но изначально Kotlin боролся именно за этот рынок). Который тоже называют «лучшей Java». Который отчасти дублирует возможности Groovy. И который быстро растёт.
В 2016-м Gradle объявили, что билд-скрипты станет можно писать не только на Groovy, но и на Kotlin. И это в Groovy-сообществе многие восприняли как удар в спину. В своё время Gradle помогло использование языка, который нравился многим разработчикам куда больше XML из Maven. И теперь, став популярным не без помощи Groovy, Gradle поддержал заклятого конкурента!
Правда, работа над Kotlin DSL растянулась настолько, что только в конце 2018-го (спустя два с лишним года после анонса) он получил статус «production ready», так что на данный момент мир всё ещё никуда не ушёл от Groovy в Gradle-скриптах.
Наконец, возвращаемся в настоящее. Седрик Шампо объявляет об уходе из Apache Groovy, и в своём посте объясняет причины.
Он работает в Gradle Inc, и пишет, что его жизнь усложнилась с того момента, когда было объявлено о поддержке Kotlin в Gradle. Каждый раз, когда он говорил что-либо хорошее о Kotlin, люди из Groovy-сообщества писали ему «не надо так, ты вредишь Groovy», «вы там в Gradle не на нашей стороне»…
При этом Седрик не рассматривает Kotlin как угрозу для Groovy, ему нравятся оба языка, он пользуется обоими, видит в обоих свои преимущества. В последнее время ему интереснее Kotlin — но для него это не означает какого-то «перехода на другую сторону баррикад», он не привязывает свою личность к выбору любой конкретной технологии. В итоге он устал от ощущения борьбы и ему стала некомфортна ситуация, когда он не может просто упомянуть язык, не сталкиваясь с возражениями и подшучиваниями.
Последней каплей стало то, что на днях он закоммиттил в Apache Groovy билд-скрипт, написанный на Kotlin Gradle DSL (что вызвало возражения). По словам Седрика, люди заявляли, что он принял такое решение из-за работы в Gradle Inc, а такое он терпеть не готов:
«I am Cedric. I am not Gradle Inc.
I am Cedric. I am not Kotlin.
I am Cedric. I am not Groovy.
Technologies live and die, I’m not interested in being married with a technology».
В этом можно было бы увидеть историю «ужасного сообщества, загнобившего человека» — но Седрик подчёркивает, что он сам совершенно не считает сообщество Groovy токсичным. Он считает, что там просто много страха за будущее (вполне объяснимого), и объясняет действия людей этим.
Если считать его трактовку правильной, то история вырисовывается такая: сообщество опасается за будущее языка, но из-за этих опасений само создало атмосферу, от которой ушёл яркий и полезный представитель. То есть, желая Groovy лучшего, в итоге сделало хуже.
В самом сообществе, впрочем, есть и другая трактовка: на самом деле добавление билд-скрипта на другом языке вызвало не религиозный ужас, а вполне разумные возражения вроде «это ненужное усложнение проекта, не все знают этот язык». И с такой трактовкой история начинает выглядеть совсем иначе.
Чтобы составить собственное мнение, можете прочитать, например, обсуждение этого коммита.
В любом случае, история печальная. Но, к счастью, закончившаяся хотя бы не скандалом, а многочисленными благодарными реплаями Седрику за всё, что он сделал для Groovy.
Минутка рекламы. Раз вы здесь, вероятно, вам интересна разработка на Java/JVM-языках — а в таком случае может быть интересна и конференция JPoint (Москва, 5-6 апреля). На этом JPoint не будет докладов конкретно по Groovy, зато среди спикеров есть коммиттер Apache Groovy Сергей Егоров — так что, если вам интересен этот язык, на конференции будет с кем о нём поговорить.
Комментарии (8)
GeraJet
23.03.2019 09:24Поведение сообщества, если все действительно так, похоже на какую-то дешевую мелодраму.
poxvuibr
23.03.2019 12:26+1Вот тип взял и закомитил в Apache Groovy билд скрипт на языке, который сообщество Groovy считает враждебным конкурентом. И он был в курсе, что в сообществе Groovy Kotlin не любят. Вот какой реакции он ожидал?
justboris
23.03.2019 13:51+1Есть такой важный аспект как dogfooding. Как можно делать язык более удобным для пользователей, если самим его не использовать?
OnYourLips
23.03.2019 12:47+2Последней каплей стало то, что на днях он закоммиттил в Apache Groovy билд-скрипт, написанный на Kotlin Gradle DSL (что вызвало возражения).
Я убежден, что сообщество правильно отреагировало.
Представьте, что вы пишете проект на python, а туда вместо tasks.py запилиили Rakefile (Ruby).
Или в документацию вашего проекта некто Ван Нгуен добавляет страницы на вьетнамском вместо английского.
Ruby и вьетнамский язык сами по себе не плохие, но они неуместны в этих случаях.forester11
23.03.2019 15:09+1Ну если уж продоожать эту мысль, зачем разработчикам Java изучать новый Groovy для билд скриптов Gradle? И зачем вообще Gradle если Maven вполне способен все собрать? :)
Я не JVM разработчик но сталкивался с ситуациями когда пытались прикрутить Gradle для CI — и честно, я непонимаю зачем он весь (и Groovy вместе с ним) нужен. Так как уже есть jenkins pipeline, maven (java), cmake/msbuild/ninja (плюсы). Изучать поверх этого Gradle + Groovy кажется чем то абсолютно избыточным и неуместным.
OnYourLips
23.03.2019 15:27Ну если уж продоожать эту мысль, зачем разработчикам Java изучать новый Groovy для билд скриптов Gradle? И зачем вообще Gradle если Maven вполне способен все собрать? :)
Потому что это языки разного назначения с разной сложностью запуска и конфигурации. Хороший пример — скрипты на bash или python в проекте на C++ для конфигурации. А вот для проектов на Ruby подобное уже не нужно.
Для Groovy Kotlin избыточен и вреден, он вносит лишь дополнительную сложность поддержки не привнося какой-либо пользы.
w0den
23.03.2019 16:38+1Думаю, это некорректное сравнение, поскольку «Ван Нгуен» не пытается заменить английский вьетнамским, а лишь добавляет поддержку нового языка. Кто не знает вьетнамский — просто читает документацию на английском. А вот вьетнамский язык может оказаться хорошим плюсом и привлечь в этом проекте дополнительных участников.
К тому же, Седрик Шампо не просто «ещё один» участник проекта, а тот, благодаря кому в проекте появились хорошие и полезные фичи (то есть, он явно не дилетант). Возможно, с его профессиональной точки зрения такие изменения хороши, когда другие не понимают его и ошибочно считают, что это неправильно (так сказать, эффект Даннинга — Крюгера, только с этим проектом всё сложнее, поскольку Седрик не является единственным профессионалом).
vics001
Ушел и ушел. Устал. Groovy уже точно останется надолго и в Gradle, и в Jenkins Pipeline / configuration, и какой крутой скриптовый язык на JVM. Возможно, кто-то хотел сделать из Groovy системный язык, куда стремится Kotlin, а получился отличный скриптовый + Groovy DSL, благодаря которому мы и получили лучшую билд-систему.