Экономика выбора: Python, Java, Go при разных RPS. Деньги или скорость?

Сегодня проведём полный экономический анализ для каждого языка программирования, основанный на реальных данных и кейсах и покажем, как количественно оценить trade-off между скоростью разработки и производительностью, учесть долгосрочные затраты на поддержку кода.

В меню — исследования скорости разработки, стоимость изменений, скорость обновления кода для разных отраслей, стоимость инфры. Учитывая эти факторы, посчитаю для скольких RPS экономически оправдано использовать тот или иной язык разработки.

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

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

Сразу скажу, что будем рассматривать стандартные задачи на бэкенде: API, CRUD, CMS. Мы не будем смотреть на раздачу видеочанков или склейку, приём, передачу файлов, а рассмотрим самое популярное.

Причины выбора неоптимального языка и как с этим бороться

Почему вообще в индустрии так происходит и некоторые очень неподходящие инструменты используют — например, пилят CMS на Go?

Выбор «ради резюме» (Resume Driven Development) или следование хайпу (Hype Driven Development)

Разработчики часто не против на чём-то переписать, что им интересно, и добавить строчку в резюме — особенно на том языке, на котором больше платят. А еще есть хайп — например, язык, который отлично работает с памятью, на котором мало специалистов. Например, у нас есть CMS со 100 посетителями в день. Разработка на Python Django займёт 2 недели, на Go — 2 месяца. Это, конечно, бьёт по бюджету:

• Увеличение времени разработки на 30-50% из-за изучения новых технологий на проекте.

• Рост затрат (Senior Go-разработчик + 20-40% к Java).
• Риск выбора незрелых технологий.
• Затраты на миграцию, когда хайп спадает.
• Сложность найма.
• Упущенная выгода от более быстрого time-to-market.

Как бороться

• Создать техническое ТЗ с чёткими метриками (RPS, время разработки, бюджет), чтобы не было большого разбега по выбору языка.

• Создать критерии зрелости технологий — тот же техрадар, чтобы не привозили совсем новые супермодные языки.
• Делать POC с измерением реальных метрик, то есть готовый прототип.

Хочешь на Go сделать — иди, сделай за две недели прототип, сделаешь — хорошо, можно посмотреть.

• Ввести экономическое обоснование выбора технологий в процесс принятия решений.

Ограниченная компетенция команды

Команда пишет на одном языке, нужно сделать что-то лёгкое — соответственно, работает только на этом языке и не использует возможности других. Например, API метаинформации можно сделать на Java Spring за месяц, хотя на Python FastAPI разработка займёт неделю. В результате:.

• Растёт ФОТ.
• Замедляется разработка простых задач.
• Замедляется time-to-market и продукт выходит на рынок позже конкурентов.

Как бороться:

Вообще T-Shaped компетенции сейчас диктует рынок. Мне кажется, все должны сегодня идти в эту сторону.

Синдром «серебряной пули»

Когда говорят, что мы выберем один язык (Java, C#, Node.js и пр.), и через два шага сэкономим там на девопсах. Может и так, но надо рассчитывать экономическое обоснование, считать полную стоимость работы. Такой подход может привести к использованию дорогих языков для простых задач, переусложнению архитектуры и в итоге к росту TCO (Total Cost of Ownership).

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

Влияние ЯП на деньги

В индустрии есть тренд — переписывать микросервисы с Python на Go, чтобы вырасти в производительности, сэкономить на инфраструктуре. В моём представлении это примерно так выглядит:

Выбор языка — это не про хайп, а про деньги.

Очень важно рационально выбирать язык разработки. Иначе вы столкнетесь с:

• Оверинжинирингом: преждевременно заложите или оптимизируете то, что пока еще не нужно, то, что ещё не болит.
• Раздутым ФОТ:если мы выбираем язык разработки, который популярен у банков, то начинаем соперничать с ними по зарплатам разработчиков — фонд может раздуваться. Выбираем популярный язык — переплачиваем.
• Дефицитом специалистов: в индустрии есть язык с защищённой работой с памятью, но разработчиков на нём практически нет. Если мы его выбираем, то тоже будем переплачивать за них.

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

Python 30–45 дней.

Java 40–55 дней.

Go 60–90 дней.

Это влияет на три важных фактора:

• Time-to-Market: если ты выходишь на рынок вторым, третьим или четвёртым, на маркетинг потребуются в разы больше трат. Опоздание с изменениями — тоже провал. Соответственно, если выбираем более медленный язык, на котором мы не успеваем завести в прод изменения, это фиаско.
• Объём техдолга: языки, на которых медленнее писать, как правило, чаще порождают техдолг. Почему? Потому что бизнесу нужно всегда срочно и быстро. Разработчики находятся под гнётом, часто идут на сделки с совестью, и, таким образом, техдолг растёт быстрее, чем на более быстрых ЯП.
• Наличие готовых решений: выбирая язык разработки мы выбираем ещё и экосистему. Например, они сильно развиты в Python или в Java. Но в экосистеме Java, как правило, одна-две библиотеки энтерпрайз уровня, которую все используют. В Python может быть 3−4 библиотеки, которые конкурируют между собой и развиваются, используют внутри себя разные подходы. В Go тоже не стоят на месте, но это относительно молодая экосистема, много придется писать самому.

Чтобы составить экономическую модель, в первую очередь нужно посчитать скорость разработки на трёх языках.

Сравнение скорости разработки Python, Java, Go

Для сравнения скорости разработки нужно взглянуть на исследования. Но чтобы в них разобраться, начнём с методологии.

Скорость разработки очень сложно измерить — всё зависит от уровня и фреймворков.

Типы исследований по скорости разработки:

Контролируемый эксперимент

Выделяем группы разработчиков примерно одинакового уровня — например, по 80 человек на каждом языке. Им ставится рабочая задача, они её решают, замеряется время разработки. Это ресурсоёмко, дорого и очень накладно.

• Анализ объёма кода (SLOC/LOC/FP)

Берём большое количество проектов: анализируется количество кода, этот код переводится в функциональные единицы — считается, сколько строчек кода нужно написать, чтобы была запись в файл или в БД. Это косвенная метрика, которая считается на большом количестве проектов, чтобы можно было говорить о статистически значимых числах.

• Анализ репозиториев и истории изменений

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

• Анализ эталонных задач

Методика похожа на контролируемый эксперимент, но разница в том, что эталонная задача слабо коррелирует с нашей работой. Это из коллекции Rosetta в основном, но есть группа исследований, которые это анализируют.

У нас есть три языка. Сначала сравним Python с Java, потом Python с Go, получим цифры и их заложим в модель. Все эти показатели вы сможете в своей экономической модели использовать по-разному.

Время разработки фичи на Python, Java, Go

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

Время разработки фичей на Python возьмем за 1, на Go — чуть побольше, на Java — больше всего.

Почему скорость разработки на Python выше:

• Лаконичный синтаксис: гораздо меньше нужно переводить свои мысли на компьютерный язык, меньше нужно писать.
• Встроенные высокоуровневые структуры данных.
• Богатая стандартная библиотека: это очень важно для закрытых контуров, где нельзя использовать внешние библиотеки.
• Много паттернов из коробки: Python практически чемпион по паттернам разработки из коробки. Там есть итераторы, генераторы, декораторы, контекстные менеджеры и т.д..
• Огромная экосистема сторонних библиотек: 690 585 проектов, 7 544 042 релизов, 15 848 980 файлов и 968 886 пользователей.

Да, конечно, из почти 700 тысяч не все библиотеки энтерпрайз-уровня. Но обычно есть 3−4 библиотеки для каждой задачи, которые нам нужны.

Скорость изменения кода. Когнитивная нагрузка и количество строк

• Чем больше объём кода, тем выше когнитивная нагрузка: представим, что разработчик вернулся из отпуска, забыл все пароли, «обнулился», а ему надо срочно баг исправить. Ему нужно весь объём кода проанализировать. Чем больше кода, тем больше когнитивная нагрузка на человека, приходится держать в голове всю структуру.
• Каждая строка кода — потенциальное место для ошибки: вероятность ошибки примерно так рассчитывается: количество строк кода умножить на сложность каждой строки. Под сложностью имеется в виду не атомарная операция языка, а что-то типа: если написано lambda, выполняется 10 операций, и непонятно, что происходит.
• Меньше кода — меньше багов: на этот счёт есть много исследований. На каждую 1000 строк кода добавляется где-то 2−5% вероятности появления бага. Напомню, что конце статьи будет ссылка на справку, где подробно приведены все исследования.
• Меньше кода – быстрее изменения, потому что меньше merge conflicts

Производительность Python, Java, Go на примере фреймворков Python FastAPI, Java Spring Boot, Go Gin

По производительности приведу два исследования.

На самом деле, это цифры не на ядро, а на сервер Xeon и реальные ядра. Если перевести на ядро (а нужно именно на ядро, потому что мы будем закладывать в экономическую модель RPS и получать количество ядер, которые нам нужно закупить), получим такие средние цифры:

Здесь исследуется отдача JSON (цифра и строка), единичные запросы в базу данных, несколько запросов в базу данных. В предпоследнем столбце Fortunes наиболее близкие к рабочей нагрузке цифры — это и запросы в базу данных, и генерация HTML с помощью шаблонизатора, в результате отдаётся готовая HTML страничка. В последнем столбце видим цифры в среднем.

Мы в KION делали свой приёмник событий. Чтобы понять, что использовать, мы провели тест.

Взяли Python 3.11, использовали асинхронный фреймворк FastAPI, написали, что он делает. Это веб-сервер, который просто принимает JSON и складывает их в Kafka. Там небольшая логика есть.

На Python мы получили 400 RPS на одном ядре и 3000 с небольшим на Go. Но при этом в Python не надо сваггер писать, там всё из коробки, в Go нужно руками всё делать.

В экономическую модель мы заложим такие цифры, но потом с этим ещё поиграем.

Тут имеется ввиду асинхронный Python. Тот, кто использует синхронный Python, удивится этим цифрам.

Мы на конференциях синхронизируемся, потому что всё изменяется. Например, в Java недавно завезли легковесную асинхронность. В Java v21 появились виртуальные потоки, в Go v18 появились дженерики, а Python последние несколько лет прибавляет в производительности в каждом релизе. В Python v 3.11 + 30%, сейчас вышел v 3.14, там 27% прибавилось. Разработчики и комьюнити знают про проблемы языка и работают над ними. Ещё в Python переписываются библиотеки, например Pydantic на Rust сильно даёт ускорение. Поэтому мы сейчас возьмем вот эти цифры, но потом их изменим и тоже посчитаем.

Цикл переписывания/обновления кода

Теперь нужно определиться с временной дистанцией, за которую мы будем платить за инфру. Есть много исследований на эту тему.

Исследование McKinsey

• Компании, использующие микросервисы:

• Обновляют компоненты 2–4 недели.
• Полностью переписывают их каждые 12–18 месяцев.

• DevOps-ориентированные компании:

• Обновления в 46 раз чаще.
• Цикл переписывания 18–24 месяца.

• Традиционные модели разработки:

• Обновление каждые 3–6 месяцев.
• Переписывание каждые 5–8 лет.

Исследование Forrester Research

• Жизненный цикл корпоративного ПО:

• 7–10 лет в крупных корпоративных системах ERP, CRM.
• 4–7 лет во внутренних бизнес-приложениях.
• 2–4 года в потребительских веб-приложениях.

Исследование Stripe

• В IT-компаниях 42% времени разработчиков – поддержка и устранение технического долга.
• Затраты на поддержку после 3 лет — + 15–20% ежегодно.
• Отраслевые различия:

• В финтехе полное обновление каждые 10–15 лет.
• В E-commerce — каждые 3–5 лет.
• В медицинском ПО — каждые 7–10 лет.

В экономическую модель заложим 5 лет, потом ещё изменим и посчитаем

Когда нужно переписывать?

Компания CAST провела исследование на основе анализа более 1,3 миллиарда строк кода и выявила главные причины переписывания кода:

• 78% — устаревание технологий.
• 42% — проблемы с безопасностью.
• 25% — технический долг слишком дорог.

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

Стоимость инфраструктуры

Я в экономическую модель взял цифры, похожие на правду — их можно будет поменять.

Реальная стоимость разработчика

У финансистов очень интересная работа: у них много нюансов на уровне наших «чем отличается ссылка от указателей в C++». А еще, пока я готовил этот блок, изменилось законодательство в части прогрессивной шкалы НДФЛ (не ко всей сумме дохода, а именно к той части, которая превысила установленный лимит). То есть, сначала платишь 13%, а если превысил лимит 2,4 млн — уже 15% и т.д.

Ещё компании платят страховые взносы:

Аккредитованная IT-компания платит 7,6%, а не IT — 30%. В 2026 году изменилось законодательство, IT-компания будет платить 15% для базы в 27 миллионов, а дальше уже 7,6%.

Теперь нам нужно взять какие-то цифры по зарплате, и мы сможем посчитать, сколько стоит разработчик. Такие цифры з/п на руки я привожу из исследований, которые есть в открытом доступе (будут в справке к статье):

• Senior Python backend dev — 280 000–400 000 руб./мес.
• Senior Java backend dev — 300 000–450 000 руб./мес.
• Senior Go backend dev — 320 000–480 000 руб./мес.

Видно, что Python-разработчики получают меньше всех, Go-разработчики — больше всех, разработчики на Java тоже неплохо живут.

Для экономической модели возьмем такие цифры:

Эти цифры бьются с теми вилками, которые мы сейчас видели. Например, если разработчик получает 300 тысяч на руки, то IT-компания платит 373 тысячи, а не IT — вообще страшно смотреть, — 451 тысячу. Если разница в з/п на руки — 50 тысяч, то компания платит больше не на 50 тысяч, а примерно на 70 тысяч.

Экономическая эффективность Python, Java, Go

Теперь рассчитаем наш проект. Думаю, все знают, чем проект отличается от продукта: проект — когда что-то сделали и больше ничего не допиливают, а продукт все время дорабатывают.

Параметры проекта:

• 10 фич.
• Rest API.
• Один разработчик.
• На Python одну фичу писать 1 месяц, на Go — 1,75, на Java — 2,5.
• Срок эксплуатации продукта — 5 лет (60 месяцев).
• RPS/Core: Python 2000 RPS, Java 4000 RPS, Go 7000 RPS.
• RAM: Python 150, Java 400, Go 20.
• Цена за инфраструктуру: CPU 350 ₽ за ядро, RAM 250 ₽ за ГБ.

Экономическая модель для разного количества RPS за 5 и 10 лет получилась следующая.

Экономическая эффективность Python, Java, Go за пять лет:

Экономическая эффективность Python, Java, Go за десять лет:

Python наиболее выгоден за 10 лет, при условии того, что мы написали фичу и больше ничего не трогали и не дорабатывали.

Python 2000 RPS на синтетике. Давайте снизим до 700?

Тесты выше — синтетические Поэтому мы для нашей экономической модели RPS снизим, причём только для Python. Для всех остальных ЯП не будем снижать.

Параметры проекта:

• 10 фич.
• Rest API.
• Один разработчик.
• На Python одну фичу писать 1 месяц, на Go — 1,75 на Java — 2,5.
• Срок эксплуатации продукта — 5 лет (60 месяцев).
• RPS/Core: Python 700 RPS, Java 4000 RPS, Go 7000 RPS.
• RAM: Python 150, Java 400, Go 20.
• Цена за инфраструктуру: CPU 350 ₽ за ядро, RAM 250 ₽ за ГБ.

Посмотрим, что будет на дистанции 5 лет:

Скорость разработки такая же, стоимость инфры для 100 тысяч RPS сильно взлетела, а RPS упали. Мы смотрим 100 тысяч, потому что меньше смотреть не так интересно — там не догонят никогда другие языки. На дистанции 5 лет при таком сетапе Go немного выигрывает на 300 тысяч у Python. Но это мы не трогали ничего, то есть написали и забыли.

Я не знаю, совпадение или нет, но у этих ребят бэк написан на Java в основном и немного на Go.

Переведём RPS в пользователей

Ко мне недавно обращался стартап — попросили помощь, говорят, что год пилят MVP и не могут доделать. На бэке у них Go — сразу правильно заложились, верят в свой продукт, что будет очень популярен сразу.

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

Количество пользователей = (RPS * 86400 секунд в сутки) / V

Здесь V — среднее количество запросов юзером за сессию. Юзеры могут ходить по экранам, и на разных экранах может быть несколько запросов на бэк. Возьмём разную среднюю активность: 50, 10 и 1 запрос.

Выходит, чтобы создавать в течение суток нагрузку 1000 RPS, к вам должны приходить 1,2% населения России в течение суток. А для 100 тысяч RPS нужно, чтобы всё население России к вам приходило на проект и ещё немного ботов (+30%). Если средняя активность — единичка (низкая активность), то всё население планеты Земля должно приходить к вам на проект, чтобы было 100 тысяч RPS.

Здесь я взял размазанное количество RPS, равномерно распределённое по суткам. Но на всех проектах есть часы пик, и мы в основном на это время закладываемся.

Переведём RPS в пользователей за 2 часа

Посчитаем, сколько должно быть приходить пользователей за 2 часа — остальных отбросим, потому что там будет меньше нагрузка.

Чтобы за 2 часа ваш продукт сгенерировал 100 000 RPS, к вам должны прийти около 12% населения России. Это серьёзная цифра.

Что в итоге?

Получается, что в экономической модели сетапа, который я привёл, Python сильно выгоднее в большинстве случаев для API, CRUD, CMS, работы с JSON и таких штук на бэке.

Когда не хватает Python, то, судя по этим цифрам, у вас должно быть столько денег (посетителей), что вы можете уже переписать проект на чём угодно. Это показывают примеры Instagram, Uber, Dropbox: они очень сильно выросли, и когда в их масштабах им уже не хватало Python, некоторые модули на Go переписали.

Кстати, Go так популярен только в России — может быть, потому, что у нас экосистем очень много.

Java традиционно себя отлично чувствует в финтехе, где сложная доменная логика и монолиты.

Где Python не подойдёт?

Я подчёркиваю: мы рассматриваем API. Python нельзя применять в системном программировании, потому что он интерпретатор. Для мобильной разработки в Python мало инструментов. Также он не подходит для GameDev и многопоточных решений. Над этим работают, к 2030 году обещают от этого избавиться. Но тогда разработчикам нужно будет уже знать примитивы синхронизации, уметь работать с памятью — вообще другой уровень.

Python vs Java

Есть множество исследований — рассмотрим только самые авторитетные.

Исследование Рэя Байшахи. Python Vs Java: анализ объёма кода (SLOC/LOC/FP):

• Количество строк кода для одинаковой функциональности.
• Проверили 700+ проектов, 80 миллионов строк кода на GitHub.
• В Python в 2,5 раза меньше строк кода по сравнению с Java.

Исследование Биссьянде. Python Vs Java: анализ репозиториев и истории изменений:

• Время между коммитами, размер изменений.
• Проверили более 100 000 проектов.
• Анализировали время эквивалентных функциональных требований. В Python в 3 раза меньше времени, чем в Java.

Python vs Go

Исследование Capers Jones (NAM Cook & Associates). Python Vs Go: анализ объёма кода (SLOC/LOC/FP)

• Сравнение продуктивности Python и Go по LOC/FP.
• Проверили 500+ проектов.
• Web/CRUD.
• Дополнение к исследованию показало, что на Python быстрее в 2-3 раза (100 FP: ~200 ч vs. 400-600 ч).

Ray et al., CACM/ICSE: A Large-Scale Study of Programming Languages and Code Quality in GitHub. Python Vs Go: анализ объёма кода (SLOC/LOC/FP):

• 729 GitHub-репозиториев на 17 языках.
• Измерение частоты багфиксов, размера изменений.
• На Python писать в ~1.5x быстрее, чем на Go. Python медленнее, чем Go, он всё-таки интерпретируемый.

И что же делать всем нам?

Финансисты и продакты не особо сильны в технике — ответственность за деньги лежит на нас тоже. Мы должны не топить за свой любимый язык, а выбирать наиболее рациональный. Сейчас нет правильного и неправильного выбора, есть рациональный и нерациональный выбор. Рынок труда требует от нас, чтобы мы развивались в сторону T-shaped, владели несколькими языками и компетенциями, тесты писали, выступали, как системные аналитики, особенно техлиды.

Нужно выбирать холодным рассудком наиболее рациональный инструмент. Если продолжать действовать как раньше, то примерно такие картины нас ждут:

А чтобы не отставать от коллег, приходите на конференцию развития Saint HighLoad++! В этом году конференция становится больше практикумом, чем лекциями, а вы — действительно участником, а не просто слушателем (послушать можно и YouTube).

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

Источник: https://habr.com/ru/companies/oleg-bunin/articles/990930/