Из Groovy ушёл Cedric Champeau? +29





В проекте 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
    /#19928768

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

  2. GeraJet
    /#19929222

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

    • poxvuibr
      /#19929812 / +1

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

    • justboris
      /#19930126 / +1

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

  3. OnYourLips
    /#19929900 / +2

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

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

    • forester11
      /#19930458 / +1

      Ну если уж продоожать эту мысль, зачем разработчикам Java изучать новый Groovy для билд скриптов Gradle? И зачем вообще Gradle если Maven вполне способен все собрать? :)


      Я не JVM разработчик но сталкивался с ситуациями когда пытались прикрутить Gradle для CI — и честно, я непонимаю зачем он весь (и Groovy вместе с ним) нужен. Так как уже есть jenkins pipeline, maven (java), cmake/msbuild/ninja (плюсы). Изучать поверх этого Gradle + Groovy кажется чем то абсолютно избыточным и неуместным.

      • OnYourLips
        /#19930520

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

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

    • w0den
      /#19930794 / +1

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

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