TL;DR: SDKMAN CLI будет переписан на Golang
Шесть лет прошло с тех пор как мы выпустили первую версию SDKMAN. В более ранних версиях он был известен как GVM и использовался для управления Groovy и связанным с ним инструментарием. Вскоре стало очевидно, что он не должен ограничиваться экосистемой Groovy, и может также применяться к другим SDK на JVM. В этот момент GVM был переименован в SDKMAN. Хотя название и изменилось, основная технология осталась прежней.
Подобно тому, как GVM однажды перерос своё имя, SDKMAN перерос технологию, на которой он был построен. Несмотря на то, что сервисы бэкенда были заменены лучшими альтернативами, CLI клиент остался прежним и стал нашим самым большим источником разочарования.
В начале мы выбрали Bash для создания GVM, потому что он закрывал все требования. Он был доступен на всех *nix системах, быстро работал и предоставлял нам среду исполнения без каких-либо дополнительных зависимостей или накладных расходов. Это означало, что загрузка новой установки практически не требовала усилий почти на любой системе.
Несмотря на преимущества, которые нам дал Bash, со временем мы обнаружили множество проблем с этим выбором:
- пользователи Windows должны прыгать через обручи, устанавливая Cygwin / Git Bash
- наше программное обеспечение не всегда хорошо работает с альтернативными оболочками, такими как Fish shell
- необходимо поддерживать специальные хаки для совместимости с ZSH
- несовместимость между основными версиями Bash (и упорный отказ Apple от поставки OSX с современной версией Bash из-за глупых вопросов лицензирования)
- проблемы с сетью из-за использования curl в качестве основного http-клиента
- сложности с эффективным тестированием кода на Bash
Все это говорит нам, что пора бросить Bash в пользу чего-то еще, поэтому в последние месяцы я начал изучать Go как жизнеспособную альтернативу. После взвешивания шансов, плюсы реализации CLI на Go можно суммировать следующим образом:
- статически типизированный компилируемый язык, позволяющий обнаруживать ошибки во время разработки
- исполняется невероятно быстро
- больше нет зависимости от зыбкой почвы Bash под ногами
- создает изначально скомпилированные двоичные файлы для всех архитектур, устраняя неожиданные связанные с платформой побочные эффекты
- более легкая поддержка приемочного тестирования через Godog (версия Cucumber, написанная в Go)
- позволяет переосмыслить некоторое поведение текущей реализации SDKMAN (подробнее об этом позже)
- позволяет улучшить сотрудничество и увеличить вклад членов сообщества
- прост и позволяет нам просто сделать эту чертову работу (Get Shit Done)
Понимая всё это, я решил построить первую рабочую версию нового CLI-интерфейса SDKMAN. После завершения этой работы новая версия станет стандартной версией SDKMAN. Конечно, это также позволит нам пересмотреть то, как он функционирует в настоящее время. Через шесть лет мы узнали, что работает и не работает, и можем довести эти знания до ума в нашей блестящей новой версии.
Здесь мы призываем наше сообщество присоединиться и стать частью общения. Мы хотим знать, какие функции вы хотели бы видеть (или не хотели бы). Для этого мы открываем новую комнату в Gitter. Мы приглашаем вас присоединиться и принять участие, давая обратную связь на новый CLI. Мы все еще используем Cucumber для описания поведения в понятном для понимания языке так же, как и в случае с версией Bash, и просим всех принять участие в реализации каждой функции. Как и прежде, мы хотим, чтобы эти функции составляли живую документацию.
Именно поэтому я назвал этот пост так. Нам нравилось разрабатывать оригинальную версию SDKMAN, но мы поняли, что в ней есть проблемы. Теперь у нас есть возможность сделать его более надежным и улучшить его для всех. Мы будем рады любой помощи на пути к реализации нового CLI!
От переводчика: SDKMAN — один из самых любимых мною пакетных менеджеров, с него начинается установка JVM, Gradle и Kotlin на новой машине. Именно поэтому, совсем недавно мы в CUBA Platform начали публиковать в SDKMAN свою утилиту CUBA CLI. Я сделал этот перевод, поскольку рад видеть развитие SDKMAN и с нетерпением жду его новой версии.
Borz
OFF: в голосовалке не хватает пункта "иное" — пришлось воздержаться.
А вообще молодцы — для их проекта уже давно пора было от скриптов уйти
jreznot Автор
Немного странно только, что Go. Но ничего стабильнее наверное просто не существует, Kotlin/Scala native слишком молоды, а Rust просто сложный.
SirEdvin
Вы не поверите, для скриптов есть python) Довольно стабильный.
Borz
и возвращаемся к проблеме как с Bash :) разные версии, необходимость что-то ставить на Windows, etc
kalininmr
везде есть 2.7
ну и для скриптов отлично пишется универсальный код. там затык только с бинарными данными
Borz
Ах если бы это было так. Когда-то для себя выбирал на чём скриптоваться и выбрал bash
kalininmr
ну тогда и bash не совсем везде :)
Sirikid
Если уж и завязываться на шелл, то только на POSIX sh.
domix32
найдете в дефолтной windows python 2.7? А так да все чаще желаю смерти bash в пользу python
kalininmr
в bash там какой версии подефолту? :)
Borz
Так одна из причин ухода с bash как раз из-за того, что его в Win нет по-умолчанию.
kalininmr
я сравнивал bash vs python.
наличие примерно одинаковое.
а писать на питоне всяко удобнее.
mad_nazgul
Наверное, потому что «стильно, модно, молодежно».
А так ко второй версии изменять систему работу с модулями, добавят дженерики и работу с исключениями. Вот тогда Go можно посмотреть. :-)
ggo
Serverless… же
deployment time становится фактором, на который обращают внимание.