Pull to refresh

Comments 42

В плане написания вот таких банальных утилит Go однозначный чемпион и вообще мастхев для DevOps инженера. Хоть я и ненавижу Go, эту его сильную сторону приходиться признать. Поэтому мне кажется вообще идея на этом поприще Котлин с ним сравнивать не очень то удачной. Вот если бы его с С сравнивали я бы ещё понял а так это выглядит странным. Да и вообще, слышал от Джавистов с которыми работаю что Котлин клевый и удобный под JVM. Пытаться его сделать натив при этом во всю используя СLang это ИМХО натягивание совы на глобус. Как тот же JS для микроконтроллеров. Да, если кто не знал, на JS можно под микроконтроллеры писать. Как страшно жить.
Для JVM у Kotlin действительно все прекрасно. Но вот JetBrains уже пару релизов экспериментируют с кроссплатформенностью. Скорее всего видят там какой-то потенциал.
В плане написания вот таких банальных утилит Go однозначный чемпион и вообще мастхев для DevOps инженера

Подскажите, пожалуйста, а почему не python? На серверах он у вас скорее всего есть, на рабочей станции тоже. Для простых утилит даже нет необходимости что-то доставлять — все есть из коробки.

В общем да, питон крут НО его надо ещё поставить. Хотя да, обычно он и так есть. Ну Го таки вывозит единым бинарем, тем что больше ничего не надо ставить и тем что почти все что нужно есть в стандартной библиотеке. Я как то писал такую вещь на C# и ради такой фигни подключать какие то либы, проверять есть ли дотнет вообще не охота. И на питон тоже писал такие утилиты. Также история. А с Go — взял и пишешь не о чем не парясь, все есть в стандартной либо и все запускается на месте. С другой стороны, для больших и серьезных проектов все преимущества Go сходят на нет. Для такого проекта поставить JVM/CLR(.net) не проблема. В них при любом раскладе с десяток библиотек подключённой, они обычно вообще весь сервер и все его ресурсы себе забирают и т. д.

У меня сервера настраиваются при помощи ansible, так что питон там уже стоит по умолчанию. Как-то так.

А нужные библиотеки могут там не стоять
Как-то так

image


В реальном мире у вас обычно есть какая-то система конфигурации серверов, в моем случае ansible, при помощи которой вы деплоите приложения на сервер. В итоге это нужно настроить только один раз и такой проблемы больше нет (исключая проблемы с обертками над с-шными либами, но такая проблема есть абсолютно везде, к счастью в python хватает pure-python или pure-c реализаций, которым нужен только компилятор).


Если же мы говорим про одноразовый скрипт, то обычно есть две опции:


  1. Вам в 90% случаев хватает довольно обширной коллекции библиотек из коробки.
  2. Если вам нужен скрипт для работы с каким-то куском вашего приложения, которые тоже написано на python, у вас там уже есть окружение для его запуска.
  3. Ну и в совсем плохом случае, которых откровенно безумно мало, таки приходится немного страдать.

В реальном мире установка зависимостей лишь одна из довольно обширного класса задач инструментирования приложений, и если у вас она настолько ручная, что один бинарник это невообразимое преимущество, которое может кого-то впечатлить — это очень печально.

Отсутствие зависимостей всегда лучше их наличия и ansible тут не панацея.


  1. Тулзе А нужна 2.2 версия, а тулзе Б 3.1. Блин, надо virtualenv настраивать?
  2. Потом pip или yum — чем мы там python зависимости ставим? А уже везде дефолтная версия python3? Ахх, тут на 100 серверах yum'ом установили, а на другой сотне pip'ом.
  3. Блин, ansible yum модуль поставил библитеку libA-2.3.0 хотя я явно же написал поставить libA-1.9.0 (ох state: latest игнорит версию в названии пакет).
  4. Блин, 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 в бинарник, даже собрать просто все в один файл, необходимый инструментарий для того, что бы вообще не было проблем с управлением зависимостями на серверах (контейнеризация, например), но если для вас это все какое-то либо преимущество перед другими языками, то это ваше право.


Мое мнение в том что преимуществом должно быть что-то, что еще не реализовали в других языках, или же это подключается жуткими костымями. Например, тот же шедулинг. Но сборка в один файл, серьезно? Я как-то уже года три минимум работаю с питоном и никогда не было такой проблемы.

То есть вы мне предлагаете сделать что-то (как virtualenv или собрать python в бинарник) вместо того, чтобы ничего этого не делать и называете это преимуществом?

Простите, вы же собираете го в бинарник, вместо того что бы деплоить прямо кодом. Что мешает так сделать с питоном?


Ну и нет, лично мое мнение по поводу того, почему cli тулзы лучше писать на интерпретируемых языках я написал выше. Вкратце, их проще писать, проще дебажить куда быстрее поправить, если они сбоят в каких-то местах. Не говоря уже о том, что значительное количество тех же веб фреймворков позволяют просто запустить условную консоль внутри, что значительно снижает необходимость в таких мелких инструментах.


Необходимость собирать в бинарник или использовать virtualenv (я предпочитаю этот вариант) это больше неудобство, чем проблема.

В Go я делаю вот так `GOOS=linux go build` и запускаю бинарник на сервере. А как это сделать с python?

> Необходимость собирать в бинарник или использовать virtualenv (я предпочитаю этот вариант) это больше неудобство, чем проблема.

Так разве удобство это не преимущество?
UFO just landed and posted this here
Думаю что C-подобный синтаксис, простота синтаксиса и единый бинарник на выходе. А кто чемпион по Вашемму мнению?

Питон ещё претендует но там одна проблема — его ещё поставить надо хотя да он обычно и так уже стоит.

UFO just landed and posted this here
Если это планируется использовать где-то кроме как в качестве обучения, то почти все ОС предоставляют специальные механизмы для отслеживания изменений файлов, чтобы не делать while (true) { ... }. Гугл подсказывает, что есть кросс-платформенные библиотеки, например — github.com/emcrisostomo/fswatch
Тысячи разных filewatcher'ов, на любой вкус и цвет. Цель была все же разобраться что предоставляет (и не предоставляет) Kotlin Native, а не написать еще один.
Когда вы пишите command line утилиту, последнее, на что вам хочется полагаться, так это на то, что на компьютере где она будет запущена установлен JVM, Ruby или Python

На практике получается, наоборот. Последнее, что мне бы хотелось, это что бы она была написана на комбилируемом языке и падала с паникой где-то внутри.

А почему паника хуже чем непойманный эксепшн? И там и там аварийное завершение, и там и там стектрейс.

Очевидно, потому что в случае интерпритируемого языка есть надежда это поправить так сказать, на месте.

Скачиваете исходник утилиты и патчите, в чём проблема?

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

Я пытался провернуть такое с traefik, но схема собери и запусти не работает без настроенного рабочего окружения с этими всеми GOPATH и прочим.

Тот же gitlab мне было гораздно проще пачтить (хотя руби я не знаю еще хуже, чем golang), потому что это сводилось к изменению файликов :)

Опять же, если вы используете golang в своей работе — этой проблемы не будет.
Я пытался провернуть такое с traefik, но схема собери и запусти не работает без настроенного рабочего окружения с этими всеми GOPATH и прочим.

А говорят в Go очень низкой порог вхождения, оказывается не такой уже и низкий.
Это специфика наркотика известного как «интерпретируемые языки». После них очень сложно привыкнуть к тому, как сделан дебаг в компилируемых языках.

Ну и кстати, про GOPATH я зря сказал, оказывается, наконец-то можно запустить hello-world без переменных окружения.
Debug везде примерно одинаковый, не? Или ты про REPL?

А GOPATH вот недавно только профиксили. Не прошло и 8и лет, ага.
Debug везде примерно одинаковый, не? Или ты про REPL?

REPL + возможность встроить дебаг поинт прямо в код (не знаю, если ли такое в компилируемых языках, не попадалось) + тот факт, что исходники почти всегда с программой поставляются :)

REPL в том же Go сильно не хватает, да.

В C/C++ есть трюк с


void breakpoint() {
    __asm__ __volatile__("int3");
}
Тут все относительно: с каким языком сравнивать и куда именно нужно входить.

Если сравнивать с каким-нибудь C/C++, действительно начать писать на нем проще.
Если же писать на нем какой-нибудь concurrent код, то не все так однозначно. А с написанием business logic там все вообще очень плохо.
UFO just landed and posted this here
Боюсь, если бы у нас не было интерпретируемых языков, датацентры были бы в 20 раз больше, все было бы в угле, никто бы в здравом уме не доверял бы компьютерным системам, потому что каждая вторая была бы решетом, а куча людей, которые топят за комбилируемые языки и прямое управление памятью оказались бы на улицах, потому что говорить они все мастаки, а про утечки и двойную очистку памяти, переполнения и прочее прелести в таких языках они почему-то забывают.

Ну и ентерпрайз рестарты раз в час в каждой второй системе, куда же без них.
Даже не знаю, что меня смущает больше: разделение на «скриптовые» и «интерпретируемые», или то, что Java причисляется к «интерпретируемым».

But I'll bite. Какую альтернативу предложишь?
По началу не понял связи, в интерпретируемых языках ведь так же можно получить exception. Но видимо ты о ситуации, когда утилита есть, а исходников нет?
В целом — да. Или когда разработчик утилиты не моя компания, например.
Так большинство утилит будет сделано какой-нибудь другой компанией.
Есть же PR, есть fork в конце-то концов.
было бы интереснее почитать об опыте использования java Ahead-Of-Time компиляторов. Я знаю о двух: Excelsior JET и jaotc из JDK9+.
Куча людей пишет мультиплатформенные проекты на koltin в IDEA, они спокойно компилируются и в Native и в JS. Так что читать статью о том что kotlin native не торт, от человека, который даже IDE не настроил, это ну как-то, ну сами понимаете.
Проверил, ты прав, теперь и IntelliJ позволяет создавать Kotlin/Native проекты. Еще пару месяцев назад такой возможности не было.

filename.split(".").last() -> filename.substringAfterLast(".") :)

Спасибо, действительно элегантней :)
Sign up to leave a comment.

Articles