В проекте 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)


  1. vics001
    23.03.2019 02:21

    Ушел и ушел. Устал. Groovy уже точно останется надолго и в Gradle, и в Jenkins Pipeline / configuration, и какой крутой скриптовый язык на JVM. Возможно, кто-то хотел сделать из Groovy системный язык, куда стремится Kotlin, а получился отличный скриптовый + Groovy DSL, благодаря которому мы и получили лучшую билд-систему.


  1. GeraJet
    23.03.2019 09:24

    Поведение сообщества, если все действительно так, похоже на какую-то дешевую мелодраму.


    1. poxvuibr
      23.03.2019 12:26
      +1

      Вот тип взял и закомитил в Apache Groovy билд скрипт на языке, который сообщество Groovy считает враждебным конкурентом. И он был в курсе, что в сообществе Groovy Kotlin не любят. Вот какой реакции он ожидал?


    1. justboris
      23.03.2019 13:51
      +1

      Есть такой важный аспект как dogfooding. Как можно делать язык более удобным для пользователей, если самим его не использовать?


  1. OnYourLips
    23.03.2019 12:47
    +2

    Последней каплей стало то, что на днях он закоммиттил в Apache Groovy билд-скрипт, написанный на Kotlin Gradle DSL (что вызвало возражения).
    Я убежден, что сообщество правильно отреагировало.

    Представьте, что вы пишете проект на python, а туда вместо tasks.py запилиили Rakefile (Ruby).
    Или в документацию вашего проекта некто Ван Нгуен добавляет страницы на вьетнамском вместо английского.
    Ruby и вьетнамский язык сами по себе не плохие, но они неуместны в этих случаях.


    1. 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 кажется чем то абсолютно избыточным и неуместным.


      1. OnYourLips
        23.03.2019 15:27

        Ну если уж продоожать эту мысль, зачем разработчикам Java изучать новый Groovy для билд скриптов Gradle? И зачем вообще Gradle если Maven вполне способен все собрать? :)
        Потому что это языки разного назначения с разной сложностью запуска и конфигурации. Хороший пример — скрипты на bash или python в проекте на C++ для конфигурации. А вот для проектов на Ruby подобное уже не нужно.

        Для Groovy Kotlin избыточен и вреден, он вносит лишь дополнительную сложность поддержки не привнося какой-либо пользы.


    1. w0den
      23.03.2019 16:38
      +1

      Думаю, это некорректное сравнение, поскольку «Ван Нгуен» не пытается заменить английский вьетнамским, а лишь добавляет поддержку нового языка. Кто не знает вьетнамский — просто читает документацию на английском. А вот вьетнамский язык может оказаться хорошим плюсом и привлечь в этом проекте дополнительных участников.

      К тому же, Седрик Шампо не просто «ещё один» участник проекта, а тот, благодаря кому в проекте появились хорошие и полезные фичи (то есть, он явно не дилетант). Возможно, с его профессиональной точки зрения такие изменения хороши, когда другие не понимают его и ошибочно считают, что это неправильно (так сказать, эффект Даннинга — Крюгера, только с этим проектом всё сложнее, поскольку Седрик не является единственным профессионалом).