company_banner

Из Groovy ушёл Cédric Champeau‏



    В проекте 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 Cédric. I am not Gradle Inc.
    I am Cédric. I am not Kotlin.
    I am Cédric. 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 Сергей Егоров — так что, если вам интересен этот язык, на конференции будет с кем о нём поговорить.
    JUG.ru Group
    1145,00
    Конференции для программистов и сочувствующих. 18+
    Поделиться публикацией

    Комментарии 13

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

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

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

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

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


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

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

                Для Groovy Kotlin избыточен и вреден, он вносит лишь дополнительную сложность поддержки не привнося какой-либо пользы.
                  0
                  Я разделяю ваше непонимание и с удовольствием пользовался бы системой сборки, в которой всё писалось бы на чистой Java. Не вижу никаких киллер-фич, ради которых я бы предпочёл тот же Groovy или Kotlin. Да, на Java было бы больше синтаксического мусора. Но, особенно начиная с Java 8, не так уж и больше. Зато простота понимания куда лучше. Я Gradle пользуюсь много лет, но до сих пор копипасчу решения, а когда надо самому написать — это ад, автокомплит не работает, фиг пойми, что там вообще происходит. Но тут, понятное дело, пользоваться приходится тем, чем остальные пользуются. Индустриальные стандарты и всё такое.
                    0
                    с удовольствием пользовался бы системой сборки, в которой всё писалось бы на чистой Java

                    На правах шутки — project.jerkar.org
                    0
                    зачем он весь (и Groovy вместе с ним) нужен

                    Так как уже есть jenkins pipeline

                    А ничего что Jenkinsfile это Groovy?:)

                      0
                      Тут фокус в том что об этом можно (или ненужно) знать. :)
                      Люди открывают пример, видят stages… и сразу понимают как добавить новый этап сборки. Т.е. как тут уже писали — «just copy and paste», это то что по большому счету хотят видеть все разработчики. Причем насколько я понимаю Jenkins именно навязывает эту структуру и сам разбирает файл а не отдает весь на съедение Groovy, сам сталкивался много раз с ситуациями когда конструкции Groovy не работают в некоторых местах (изза специфики Jenkins).

                      А вот Gradle + Groovy, со своими импортами зависимостей и зависимости которые могут переопределять «все что движется» приводят к ситуациями когда девелопер со стажем 10+ лет должен тратить часы чтобы понять как оно вообще собирается и кто кого зовет. Вот до такого доводить нельзя но в Gradle мне показалось достичь этого очень легко именно потому что структуру можно полностью переопределить.

                        0

                        Как опытный Jenkins-овод, могу заверить:
                        1) "Groovy не работают в некоторых местах" — это скорее бага, чем особенность, которую они так и не смогли побороть
                        2) "тратить часы чтобы понять как оно вообще собирается и кто кого зовет" — так же применимо к Jenkinsfile-ам, иногда даже ситуация гораздо хуже, чем в Gradle.
                        3) "структуру можно полностью переопределить" — это не совсем так. В Gradle действительно можно "пачкать" variable scope, но нельзя, например, переопределить "configurations {}" блок, в итоге имеем структурированность практически как в декларативном Jenkinsfile-е
                        4) "stages" в Jenkinsfile только если использовать декларативный подход, он не всегда подходит, приходится использовать императивный, и там ад и содомия похлеще Gradle файлов

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

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

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое