Интернет любит вечные войны. Linux против Windows. Vim против IDE. Tabs против spaces. Python против Java. Последняя особенно забавна: у каждой стороны есть священные аргументы, мемы и древние травмы.
Python-разработчики любят вспоминать: «В Java чтобы распечатать «Hello world» раньше нужно было написать диссертацию».
Java-разработчики отвечают: «Зато через три года мы всё ещё понимаем, что происходит».
Недавно прочитал пару больших материалов про производительность, RPS, экономику языков и выбор технологий для enterprise. В одном доказывалось, что современный Python уже достаточно быстрый. В другой пытались считать стоимость владения и стоимость разработки. Обе идеи разумные. Но после чтения осталось ощущение, будто кто-то пытается выбрать самолёт по одному параметру.
— этот летает со скоростью 900 км/ч.
А дальше вопросы:
— а он садится? А отказ двигателя переживает? А сертификаты? А кто его обслуживает?
— …так, не усложняйте.
Почему RPS — это новый FPS
Есть очень популярная болезнь инженерных обсуждений: «5000 RPS на ядро!». Звучит впечатляюще. Но RPS без контекста — примерно как FPS в играх.
Потому что 5000 RPS может означать
return {"ok":true},
а может означать REST + PostgreSQL + очередь + интеграции + авторизация + бизнес-логика + аудит + кэш + внешние API. Разница иногда измеряется не процентами — а порядками.
В enterprise почти никогда не существует абстрактного «RPS». Есть p95, p99, время восстановления, количество команд, стоимость сопровождения, вероятность ошибок, требования аудита, требования сертификации. Один синтетический бенчмарк не отвечает ни на один из этих вопросов — он просто хорошо выглядит в слайде.
Сюрприз: большие Python-системы начинают походить на Java
Есть наблюдение, которое многие замечают, но редко произносят вслух. Маленький Python-проект — это:
-
app.py
-
views.py
-
utils.py
Python прекрасен, код читается как легко, все просто и понятно.
Через три года:
-
DTO
-
Services
-
Repositories
-
Factories
-
DI
-
Adapters
-
Layer1
-
Layer2
-
Layer3
и слоями поверх слоёв. И внезапно выясняется, что команда постепенно построила Java — только без компилятора, который на тебя кричит.
Тут обычно начинается следующая стадия. Кто-то написал давно:
process(data).
Через два года:
— а что такое data?
— никто не знает.
— а почему там иногда строка?
— исторически.
— а почему иногда список?
— исторически.
— а почему иногда None?
— ….
С этого момента шутки про Java начинают казаться менее смешными.
Это не значит, что Python плохо масштабируется. Это значит, что при росте системы дисциплина и инструментарий становятся важнее синтаксиса. И тут языки начинают соревноваться на другом поле.
Почему техлиды постепенно начинают любить скучные вещи
В начале карьеры кажется: меньше кода — лучше. Потом появляется команда 20–50 человек. Потом сотни тысяч строк. Потом дежурства. Потом звонок в 3 ночи с вопросом «почему упал прод».
И внезапно оказывается, что скучные вещи обладают сверхспособностями: строгая типизация, безопасный рефакторинг, явное объявление вместо неявного, статический анализ, compile-time проверки. Вещи, которые в маленьком проекте кажутся бюрократией, в большом экономят часы отладки и нервы дежурного инженера.
В этот момент начинаешь понимать странное поведение Java-разработчиков. Они не любят типизацию. Они любят спать.
Небольшая история про AWOS
Недавно мне пришлось выбирать язык для вполне реального проекта — системы автоматической аэропортовой метеостанции AWOS (Automated Weather Observing System).
Требования там были уже совсем не из мира обычного корпоративного CRUD: сбор данных с погодных сенсоров, вычисления по алгоритмам FAA, формирование голосовых сообщений, передача по радио и на автоответчик телефонной линии, поддержка дополнительных сообщений. Например, Bird activity in the vicinity of the airport. Раньше этим занимался человек с микрофоном. Потом появились системы со словарями записанных фраз. Теперь планируется синтез речи.
Но главный нюанс был в отказоустойчивости. Даже если основной софт упал, голосовое сообщение должно продолжать работать. Просто вместо обычной погоды станция обязана говорить: weather observation not available. Это требование FAA, а не пожелание заказчика — голосовой канал для пилотов должен работать всегда.
И тут внезапно появляются слова: детерминизм, предсказуемость, сертификация, отказоустойчивость. То есть начинается уже вполне настоящий enterprise.
Почему существующие решения выглядят как археология
Существующие AWOS-системы в большинстве своем выглядят как путешествие в прошлое: специализированные контроллеры двадцатилетней давности, стоят как крыло от самолёта, но при этом умеют меньше дешёвого мини-компьютера сегодня. Зачастую TCP — отдельная опция. Шифрование? Ну вы многого хотите. Отправить что-то в JSON-е куда-то по API — забудьте.
Это создаёт нишу для современных решений. Но «современный» здесь не значит «написан на чём угодно» — сертификационные требования и промышленная надёжность никуда не деваются.
Кандидаты
Python рассматривался серьёзно. Проблема появилась на слабом железе — промышленные SBC (одноплатные компьютеры) Advantech и им подобные — это не игровой ПК разработчика. При росте числа сенсоров и скорости потока данных загрузка CPU становилась заметной. Но главная проблема оказалась неприятнее: Garbage Collector. На обычной машине редкие паузы GC можно даже не заметить. Но если у тебя в этот момент крутится голосовое сообщение для аэропорта — внезапные остановки начинают нервировать. Фраза wind two seven... [тишина] ...gusting three five может вызвать у пилотов интересные эмоции.
C — очень быстр, и GC-пауз нет по определению. Но количество кода и кроссплатформенный сетап быстро вырастают в проблему. Когда начинаешь писать третий слой оберток вокруг системных вызовов, то быстро хочется бросить проект.
Node — скриптовый язык со всеми вытекающими (производительность, GC, типизация — так себе, экосистема ориентирована на веб. Но, к счастью, мы не ограничены браузером, выбор есть.
TypeScript — логичный вопрос: зачем? TypeScript добавляет типизацию поверх JS, вроде все. Все остальные недостатки Node остаются.
Go — был серьёзным кандидатом, его каналы и корутины это как раз то, что нужно для работы с сенсорами. Но в итоге показалось, что слишком сложно настроить кросс-платформенную среду разработки, особенно для работы с COM-портами. Внезапно появились глючные C-библиотеки, нетривиальность сборки для разных вариантов железа, зависимости и прочий кроссплатформенный зоопарк, на который можно потратить дни. Преимущество простоты деплоя испарилось.
С# — для Windows наверное он бы победил, но в плане кросс-платформенной совместимости и разработки он пока недостаточно зрелый.
Почему в итоге Java
Победила Java. Не потому что «Java самая быстрая во вселенной», а потому что одновременно сошлись нужные требования.
Строгая типизация — меньше вероятность ошибок, особенно через несколько лет и с новыми членами команды.
Производительность на слабом железе — промышленные SBC от Advantech — не датацентр, но даже на нем JVM с современными GC справляется достаточно предсказуемо.
Компиляция отдельно от деплоя — собираем на быстром компьютере разработчика, разворачиваем на медленном устройстве.
Бинарная переносимость — один артефакт, разные CPU, разные ОС, меньше боли при обновлениях на парке устройств.
Современный GC — многие до сих пор обсуждают Java так, будто на дворе 2008. ZGC и Shenandoah дают паузы в единицы миллисекунд даже на больших хипах. Для голосового вывода даже на слабеньком двухъядерном Arm этого достаточно. Старые мемы больше не актуальны.
Зрелая экосистема для промышленных задач — библиотеки для работы с сетевыми протоколами и аппаратным интерфейсом давно обкатаны десятилетиями в production.
Резюме
Я не призываю переходить на Java религиозно. И не утверждаю «Python плохой». Python дейсвительно прекрасен — особенно для автоматизации, data, ML, быстрых сервисов, прототипов. Огромный класс задач решается на Python лучше, быстрее и дешевле.
Но всегда можно поставить полезный эксперимент: взять знакомую задачу и посмотреть, как это сделано в Java. Например в этом курсе. Не чтобы переехать — а чтобы сравнить: типы, инструменты, многопоточность, профилирование, упаковку, поддержку больших систем. Очень многие вещи начинают выглядеть иначе. Иногда после этого начинаешь меньше смеяться над Java.
ссылка на оригинал статьи https://habr.com/ru/articles/1038366/