Comments 42
В плане написания вот таких банальных утилит Go однозначный чемпион и вообще мастхев для DevOps инженера
Подскажите, пожалуйста, а почему не python? На серверах он у вас скорее всего есть, на рабочей станции тоже. Для простых утилит даже нет необходимости что-то доставлять — все есть из коробки.
В общем да, питон крут НО его надо ещё поставить. Хотя да, обычно он и так есть. Ну Го таки вывозит единым бинарем, тем что больше ничего не надо ставить и тем что почти все что нужно есть в стандартной библиотеке. Я как то писал такую вещь на C# и ради такой фигни подключать какие то либы, проверять есть ли дотнет вообще не охота. И на питон тоже писал такие утилиты. Также история. А с Go — взял и пишешь не о чем не парясь, все есть в стандартной либо и все запускается на месте. С другой стороны, для больших и серьезных проектов все преимущества Go сходят на нет. Для такого проекта поставить JVM/CLR(.net) не проблема. В них при любом раскладе с десяток библиотек подключённой, они обычно вообще весь сервер и все его ресурсы себе забирают и т. д.
У меня сервера настраиваются при помощи ansible, так что питон там уже стоит по умолчанию. Как-то так.
В реальном мире у вас обычно есть какая-то система конфигурации серверов, в моем случае ansible, при помощи которой вы деплоите приложения на сервер. В итоге это нужно настроить только один раз и такой проблемы больше нет (исключая проблемы с обертками над с-шными либами, но такая проблема есть абсолютно везде, к счастью в python хватает pure-python или pure-c реализаций, которым нужен только компилятор).
Если же мы говорим про одноразовый скрипт, то обычно есть две опции:
- Вам в 90% случаев хватает довольно обширной коллекции библиотек из коробки.
- Если вам нужен скрипт для работы с каким-то куском вашего приложения, которые тоже написано на python, у вас там уже есть окружение для его запуска.
- Ну и в совсем плохом случае, которых откровенно безумно мало, таки приходится немного страдать.
В реальном мире установка зависимостей лишь одна из довольно обширного класса задач инструментирования приложений, и если у вас она настолько ручная, что один бинарник это невообразимое преимущество, которое может кого-то впечатлить — это очень печально.
Отсутствие зависимостей всегда лучше их наличия и ansible тут не панацея.
- Тулзе
А
нужна 2.2 версия, а тулзеБ
3.1. Блин, надо virtualenv настраивать? - Потом
pip
илиyum
— чем мы там python зависимости ставим? А уже везде дефолтная версия python3? Ахх, тут на 100 серверах yum'ом установили, а на другой сотне pip'ом. - Блин, ansible yum модуль поставил библитеку libA-2.3.0 хотя я явно же написал поставить libA-1.9.0 (ох
state: latest
игнорит версию в названии пакет). - Блин, OS команда не дает нам root (не доверяют), а мне надо бы новую зависимость установить, опять virtualenv настраивать, а как же с C зависимостями?
И так далее.
Преимущество есть и оно большое (может быть конечно не "невообразимое").
Тулзе А нужна 2.2 версия, а тулзе Б 3.1. Блин, надо virtualenv настраивать?
В случае с python вам нужно настраивать virtualenv вообще всегда, если вы не выпускаете тулзу для дистрибутивов и встраиваете ее в правильный pipe ее менеджера пакетов. И вместе с этим уходят вопросы 2 и 3.
Блин, OS команда не дает нам root (не доверяют), а мне надо бы новую зависимость установить, опять virtualenv настраивать, а как же с C зависимостями?
Дает доступ на сервер, но не дает рут доступ? Я смотрю у вас ОС команда еще те выдумщики, учитывая, сколько есть возможностей и эскалировать доступ в случае чего, и понаставить магии. Ну и да, если у вас у разработчиков нет возможности лазить на сервер и делать то, что им надо — фиксите процессы. Либо оно на самом деле им не надо, либо если таки надо, то надо возможность им давать.
Опять же, С зависимости у вас могут быть и в go, например для imagemagick. От них вообще ничего не спасает.
Отсутствие зависимостей всегда лучше их наличия и ansible тут не панацея.
Я побью это картой "интерпретируемые языки для cli тулзовин лучше, чем комбилируемые".
Нет, правда, у вас есть 1000 и 1 возможность собрать python в бинарник, даже собрать просто все в один файл, необходимый инструментарий для того, что бы вообще не было проблем с управлением зависимостями на серверах (контейнеризация, например), но если для вас это все какое-то либо преимущество перед другими языками, то это ваше право.
Мое мнение в том что преимуществом должно быть что-то, что еще не реализовали в других языках, или же это подключается жуткими костымями. Например, тот же шедулинг. Но сборка в один файл, серьезно? Я как-то уже года три минимум работаю с питоном и никогда не было такой проблемы.
Простите, вы же собираете го в бинарник, вместо того что бы деплоить прямо кодом. Что мешает так сделать с питоном?
Ну и нет, лично мое мнение по поводу того, почему cli тулзы лучше писать на интерпретируемых языках я написал выше. Вкратце, их проще писать, проще дебажить куда быстрее поправить, если они сбоят в каких-то местах. Не говоря уже о том, что значительное количество тех же веб фреймворков позволяют просто запустить условную консоль внутри, что значительно снижает необходимость в таких мелких инструментах.
Необходимость собирать в бинарник или использовать virtualenv (я предпочитаю этот вариант) это больше неудобство, чем проблема.
while (true) { ... }
. Гугл подсказывает, что есть кросс-платформенные библиотеки, например — github.com/emcrisostomo/fswatchКогда вы пишите command line утилиту, последнее, на что вам хочется полагаться, так это на то, что на компьютере где она будет запущена установлен JVM, Ruby или Python
На практике получается, наоборот. Последнее, что мне бы хотелось, это что бы она была написана на комбилируемом языке и падала с паникой где-то внутри.
А почему паника хуже чем непойманный эксепшн? И там и там аварийное завершение, и там и там стектрейс.
Скачиваете исходник утилиты и патчите, в чём проблема?
Я пытался провернуть такое с traefik, но схема собери и запусти не работает без настроенного рабочего окружения с этими всеми GOPATH и прочим.
Тот же gitlab мне было гораздно проще пачтить (хотя руби я не знаю еще хуже, чем golang), потому что это сводилось к изменению файликов :)
Опять же, если вы используете golang в своей работе — этой проблемы не будет.
Я пытался провернуть такое с traefik, но схема собери и запусти не работает без настроенного рабочего окружения с этими всеми GOPATH и прочим.
А говорят в Go очень низкой порог вхождения, оказывается не такой уже и низкий.
Ну и кстати, про GOPATH я зря сказал, оказывается, наконец-то можно запустить hello-world без переменных окружения.
А GOPATH вот недавно только профиксили. Не прошло и 8и лет, ага.
Debug везде примерно одинаковый, не? Или ты про REPL?
REPL + возможность встроить дебаг поинт прямо в код (не знаю, если ли такое в компилируемых языках, не попадалось) + тот факт, что исходники почти всегда с программой поставляются :)
Если сравнивать с каким-нибудь C/C++, действительно начать писать на нем проще.
Если же писать на нем какой-нибудь concurrent код, то не все так однозначно. А с написанием business logic там все вообще очень плохо.
Ну и ентерпрайз рестарты раз в час в каждой второй системе, куда же без них.
But I'll bite. Какую альтернативу предложишь?
medium.com/graalvm/instant-netty-startup-using-graalvm-native-image-generation-ed6f14ff7692
filename.split(".").last()
-> filename.substringAfterLast(".")
:)
Kotlin Native: следите за файлами