Комментарии 84
Где c# ?
этот TechEmpower совсем фуфлыжный тест, зачем такое приплетать к расчетам ? вон чувак разбирает на примере C# vs Java, у .Net там все фуфлыжное и реально ничего от фреймворка не используется. даже headers там константа и отдается из кеша:
https://dusted.codes/how-fast-is-really-aspnet-core
наверняка Go точно так же слил по всем пунктам и просто накрутил счетчик, как .Net
ну и тесты там устаревшие, без волшебных Java Vitrual Threads
заглянул в статью, Go там тоже есть, имплементация норм (No shortcuts or trickery to be found here), но и скорость соответственно ниже Java, причем опять ниже чем Java на обычных тредах.
и еще смешная подтасовка с TechEmpower - взят раунд 22 из 2023 года, хотя год назад состоялся раунд 23 (Fortunes), где java spring на 179, а Go gin на 284 месте
https://www.techempower.com/benchmarks/#section=data-r23
все так. 23й раунд в следующей серии. индустрия не готова к цифрам из 23 раунда. там Java сильно лучше Go.. Бигтехи только Go везде прорастили.
еще интересно что Go при работе с БД во всех тестах сдувается.
тогда следующая серия должна начаться с объяснения на кой было подсовывать неактуальные цифры из 22 раунда и делать все эти бессмысленные расчеты.
а вообще, было бы намного интересней посмотреть разбор что там реально эти дурачки натестили. не объясняется ли скачек Java читерскими оптимизациями, есть ли у Go честный темплейт енжин, честно ли они оба вычисляют размер ответа в header и прочее, что упоминал чувак про C#. мне кажется когда я заглядывал в 2025 году в round 23, там была java 21, но не было у спринга включенных Virtual Threads. ну и сейчас видно что чуваки поменяли запуск на java 23, а в pom.xml так и осталась java 21. чудики явно не понимают, что делают.
да, Virtual Threads решает. По поводу тестов. я скажу так. было несколько источников они все говорили примерно одно и тоже. Решено было оставить один самый известный. тк время 30 минут всего.
Я не вижу даже сейчас, что бы фигурировал VirtualThread в spring папочке, т.е. конкретно в раунд 23 по spring Virtual Threads ничего не решил и большой вопрос что за фигню они в 22 раунде натестили, что спринг был так низко оказался.
Ну, VirtualThread не всегда решают. Какое-нибудь решение на реактивном движке может оказаться не хуже, там в основном все зависит от эффективности nio.
Но вообще да, TechEmpower - больше про предельную производительность, которую смогли выжать, к средней скорости продакшен кода имеет очень дальнее отношение (
в данном случае речь о папочке "spring", как я вижу там совсем дефолтный спринг, без ничего. врубят VirtualThread - получат преимущество над Go gin не два раза, а в три. по спринг с реактивностью есть отдельная папочка "spring-webflux-r2dbc" и не особо там быстрее дефолтного спринга, на 2 места выше.
в целом конечно TechEmpower фигня полная, Go gin на mysql, Spring на postgres что с таким подходом сравнить хотят не особо понятно.
Кажется (но надо копаться), что если бы включение VT давало такой выигрыш, то Spring+Kotlin давал бы заметный выигрыш от Spring+Java. Но, насколько я помню, это не так.
Но про "фигня полная" согласен )
еще интересно что Go при работе с БД во всех тестах сдувается.
В go были проблемы с драйвером к postgresql. Сейчас там все норм.
Круто, но не все пилят CMS
Статья на тему: Фантастические факты и места где они обитают или как притянуть за уши все что угодно.
Например, API метаинформации можно сделать на Java Spring за месяц, хотя на Python FastAPI разработка займёт неделю.
Удобно, сами придумали факт, сами же на его основе него сделали выводы. Мне прям любопытно стало, я понимаю если бы Вы написали что на Python на 10% ну 15% быстрее чем на Java, но писать что на Python приложение будет написано x4 это прям сильно. У меня прям фантазии не хватает что будет делать Java разраб еще 3 недели.
Оверинжинирингом: преждевременно заложите или оптимизируете то, что пока еще не нужно, то, что ещё не болит.
Если в рамках стратегии - "когда у проекта настанут проблемы то я уже буду работать в другом месте и это будет не моя проблема", то норм.
Python 30–45 дней.
Java 40–55 дней.
Go 60–90 дней.
Время разработки фичей на Python возьмем за 1, на Go — чуть побольше, на Java — больше всего.
Сами придумали - сами доказали.
Чем больше объём кода, тем выше когнитивная нагрузка
Каждая строка кода — потенциальное место для ошибки
Меньше кода — меньше багов
Меньше кода – быстрее изменения
Удивительно, как же все просто в этой жизни. Зачем в Python тогда добавили типизацию? Сколько лишнего текста. Выходит что язык стал только хуже?
Видно, что Python-разработчики получают меньше всех, Go-разработчики — больше всех, разработчики на Java тоже неплохо живут.
Выглядит так, как будто бы Python еще и дешевле, но на деле - то что там ниже зп показатель что там больше всего разработчиков и следовательно качество по больнице ниже а следовательно и производительность. Странно это не учитывать.
Кстати, Go так популярен только в России — может быть, потому, что у нас экосистем очень много.
Go стал популярен по двум основным причинам. Во-первых, это палочка выручалочка для time-to-market приложений на Python/PHP/Ruby которые превратились в проблему когда компания выросла. Во-вторых, это палочка-выручалочка для HR так как в этот язык можно быстро перевербовать из любого другого.
Исследование Рэя Байшахи
Исследование Биссьянде
2014 и 2013 годы, актуальность зашкаливает. Но это не проблема когда хочется факты подтянуть за уши.
Мы должны не топить за свой любимый язык, а выбирать наиболее рациональный.
При этом в статье все подогнано под Python.
Рынок труда требует от нас, чтобы мы развивались в сторону T-shaped, владели несколькими языками и компетенциями, тесты писали, выступали, как системные аналитики, особенно техлиды.
Нет, это не рынок, это эффективные менеджеры придумывают очередные инновационные решения несуществующих проблем, сложности от которых будет решать бизнес потом, когда инноваторы будут работать уже на другом месте.
А теперь к реальности. Неожиданно, разработчики - это не стенографистки и разработка проекта это не набор теста на скорость.
По большей части что Python что Java что Go - это языки со сборкой мусора и рантаймом и как следствие, в реальности, по способу использования и скорости разработки на них не так чтобы сильно отличаются, учитывая что в Python последнее время популярна типизация с одной стороны и даже языки типа Java стали довольно сахарными то и темболее. Не нужно рассказывать сказки про x3-x4.
Язык это просто инструмент. Разработчик большую часть времени думает как решать задачу, читает код, документацию, общается а не лупит по клавишам. В реальности на скорость разработки больше всего влияют процессы, хорошая аналитика и опыт разработчика. На выбор языка в первую очередь будет влиять текущая экосистема компании, состояние рынка а не мифические показатели скорости разработки.
Удобно, сами придумали факт, сами же на его основе него сделали выводы. Мне прям любопытно стало, я понимаю если бы Вы написали что на Python на 10% ну 15% быстрее чем на Java, но писать что на Python приложение будет написано x4 это прям сильно. У меня прям фантазии не хватает что будет делать Java разраб еще 3 недели.
В статье написано 2,5 и это не личное мнение а исследования. Скорость разработки. Python высокоуровневый язык, сильно выше чем джава. поэтому и быстрей писать.
Python высокоуровневый язык, сильно выше чем джава
в чём выражается эта "высокоуровневость"?
да хотя бы в количестве строк для одного результата? банально когнитивная нагрузка меньще.
Может примерчик приведëте? Очень сомневаюсь. В ваших прошлых текстах на эту же тему видно искусственное раздувание java- кода.
изначально примеры были, но статьи огромные получаются как и доклады. я в статье по шагам про это говорю и ссылки привожу. и про скорость и про баги на 1000 строк (тут кладесь исследований). у меня нет задачи перебудить кого либо. я максимально обьективно подвсетил проблему. Котлин не брал потому что мало в проде его. Если брать котлин то будет по другому наверняка.
А можно привести ссылки на эти исследования, которые про "скорость" и про "баги"?
А то объективности пока как-то не заметно и близко.
Экий вы скользкий. Не "высокоуровневый", а "строк меньше", примеры были, но пропали, задачи переубедить нет, но однообразные статьи выходят.
Хм, меньше всего строк получается на APL (впрочем, он действительно высокоуровневый).
И вот на MUMPS гораздо компактнее выглядит код, нежели на SQL (но тут дело не в уровне).
Наверно и разрабатывать на этих языках быстрее (но нет...).
Ну и когнитивная нагрузка от числа строк вообще не зависит, разумеется )
Почему время разработки на java больше чем на go?
Какие исследования показывают, что разработка на Python больше, чем на Java?
Из процитированных исследований - это ниоткуда не следует.
Разработка на Python не больше, а быстрей и намного. вот что следует, еще следует что количество багов будет сильно меньше тк код короче, а вероятность появления багом по исследованиям зависит от размера кода. это тоже в статье. Еще есть совпадение: все сокращения которые были на нашем рынке они все на java стеке.
Ни одно из этих исследований так не утверждает (так как, вообще говоря, нигде и не сравнивает скорость разработки на Java и на Python).
Кстати, число багов в проектах на Python было (в 2014м) году заметно больше, чем в проектах на Java. Так что довод про "меньше кода - меньше ошибок" не верен (вернее, он может быть верен внутри одного языка и одного подхода к разработке, но для каждого случая надо проверять отдельно).
Статистика - это опасная штука и для работы с ней нужны некоторые базовые компетенции.
Кстати, приведи статистику, по которой все сокращения (или, хотя бы, большинство) были на java?
Какие исследования, выдуманные из головы? Потому в тех что вы привели ничего такого нет. Это вам нейросеть нагенерировала, да?
Добавлю: а еще на скорость разработки влияет качество предоставленного ТЗ, ибо нет ТЗ - результат ХЗ!
Согласен с расчетами и выводами автора, и так далеко на Хабре заходили немногие. Плюс за критику победителя и надежду. Замечу что Python требует недюжинной самодисциплины от всей команды (доменный нейминг, PEP8, типизация, доктесты) и если с этим у ключевых разрабов проблема - приучить их к лотку может оказаться невыполнимой задачей. Но обычно стартапам везет, если рук. проекта такой же малахольный и готов рефачить код за командой даже лежа на сапборде в отпуске.
Что же до интегральной денежной оценки (свести все споры к рублям) - это годно и работает в головах кодеров и головах принимающих решения (и прочих держателях стейков) - абсолютно предсказуемо, то есть точно так же. Да, иногда хочется высоких материй и "очередного доказательства 100X преимущества чего угодно над питон", но рубли приземляют: в рублях все стеки и подходы примерно равны.
А разве агентный LLM не уровнял все языки в тайм-ту-маркет? У меня LLMка одно и тоже время тратит на фичу в Python и в Rust. ┐( ˘_˘ )┌
А разве есть этому хоть какие-то объективные доказательства? Автор не фичу считал, а подход к выбору стека. Многословные языки быстро займут окно контекста и сьедят токены. TTM у стеков очень разный. И никто даже с LLM не делает релизов на двух языках сразу. Вот почему нет готовых бесспорных данных, а расчеты тут минусуют не глядя.
Расчеты как раз внимательно рассматривают. Но, увы, расчеты некорректные, начиная от исходных данных (придуманных автором и нигде не подтвержденных) и заканчивая непониманием базовых вещей в современной разработке (стоимость исправления дефектов, стоимость изменений, ориентированность на фреймворки и так далее).
Если бы статья была ровно про "производительность сервиса не так важна, как эффективность разработки" с указанием конкретных случаев, то вопросов к автору было бы гораздо меньше (ну, если бы с арифметикой не налажал бы). Но автор пытается сравнивать языки, не будучи достаточно компетентным в этом (т.е. просто не разбираясь ни в одном языке кроме Питона, да и в Питоне не очень).
Качество лучше. На питоне генерирует на мой взгляд идеально, я сам так не напишу. На джаве- от погоды и условий зависит, если миддл юзает даже годно. На котлине ересь дает. Кроме идей подсмотреть нечего. Понятно, разный возраст языков, разный объем открытой кодовой базы.
Почему скорость разработки на Python выше:
Лаконичный синтаксис: гораздо меньше нужно переводить свои мысли на компьютерный язык, меньше нужно писать.
В 2026 году: продолжаем делать вид, что Kotlin не существует.
Много паттернов из коробки: Python практически чемпион по паттернам разработки из коробки. Там есть итераторы, генераторы, декораторы, контекстные менеджеры и т.д..
Итераторы в JDK не завезли, что ли? Декораторы - ну этим, например, Spring занимается, со своим AOP.
Встроенные высокоуровневые структуры данных.
Это хорошо, когда можно выбрать из одного встроенного списка и одного встроенного dictionary? Вот в Java зачем-то придумали несколько имплементаций List и Map - от безделья, наверное.
Богатая стандартная библиотека: это очень важно для закрытых контуров, где нельзя использовать внешние библиотеки.
JDK смотрит с недоумением.
Огромная экосистема сторонних библиотек: 690 585 проектов, 7 544 042 релизов, 15 848 980 файлов и 968 886 пользователей.
Maven Central для вас шутка?
да с удовольствием Kotlin рассказывал, но его как то не много в проде. плюс нужно было только три оставить. тк доклад 30 минут.
итераторы и декораторы - для примера. помимо них еще контекстные менеджеры. да куча паттернов из коробки.
Вот в Java зачем-то придумали несколько имплементаций List и Map - от безделья, наверное. - вещь хорошая. JDK смотрит с недоумением. Да больше про сравнение с гошкой, но в патоне больше и поудобней. Есть же даже мем с гарвитацией.
Maven Central - давай считать спички.. ~600 000+ проектов https://arxiv.org/html/2504.12261, а в PyPI 736,378 проектов
Maven Central: Search: Showing 10000 results out of the 772970 available packages
Spring тоже в неумелых руках программирование превращает в конфигурирование. Не всегда быстрее и не всегда прозрачнее получается. Про быстродействие даже упоминать не стоит.
Чувак, очень далёкий от программирования, который в каждой статье облизывает phyton, но с оговоркой - "вот в играх и в мобилках, не очень, а в остальном уфффф", пожалуйста перестань ставить аргумент, что количество строк кода == время разработки = true) Прошу, ты так палишься, что не писал обдуманный код. Мне аж страшно за тебя, так как ты уже это делаешь, как минимум в трёх статьях. Тебе в каждой статье пишут, миллион комментариев, что ты не прав и ссылки у тебя идиотские (пример твой раздутый код со статьи о джаве). У меня вопрос! Почему так много плюсов в его статьях, если по комментам, статьи ужасные, это в компании накручивают?
а ну ты не допускаешь мысли что не прав? и что отрицание это первая стадия принятия? в статье максимально обьективно со ссылкой на международные исследования все показано и доказано. можно отрицать любую обьективную реальность, но от этого хуже будет точно не реальности.
а зачем ему допускать, мы же все видим что ты подогнал результат, взяв раунд 22, хотя актуальный раунд 23 привел бы ровно к противоположным выводам (не менее бредовым, учитывая абсурдность тестов).
Нет, в статье нет никаких ссылок на осмысленные международные исследования (о чем тебе много раз сказали). Более того, даже выводы из этих исследований сделать не получилось, так как со статистикой надо уметь работать. О чем тебе много раз и указывали.
"отрицание это первая стадия принятия" - самый тупой аргумент, который я когда-либо слышал.
и что отрицание это первая стадия принятия?
У вас первая стадия принятия? Надеюсь это толстый троллинг, потому что альтернатива совсем печальная)
Да, скорее всего.
Смотрел этот доклад на joker/jpoint и еще тогда возник закономерный вопрос - что за чушь автор пытается выдать за правду?
Как разработчик на java / go / python с многолетним стажем подтверждаю идею - для каждой задачи свой инструмент, свой стек, с этим спору нет. Но трудоемкость разработки на java в 2,5 больше по "каким-то смутным исследованиям"? Серьезно?
Это может быть правдой только в том случае когда берем абстрактного джуна в вакууме и дадим ему изучать с нуля стеки разработки. Для людей, плавающих в технологии, реализовать CMS не составит труда что на одном, что на другом ЯП. Фреймворки берут всю рутину на себя, разработчику остается писать прикладной код. А в случае с CMS он будет по своей сути одинаков.
К слову, из анализа упущен важный момент - стоимость рефакторинга. Если в Java /Go со строгой типизацией и проверками на этапе компиляции все ок, то с python где проверки лишь уровня линтера - такое себе, есть не иллюзорный шанс в рантайме словить ошибки.
Время разработки фичей на Python возьмем за 1, на Go — чуть побольше, на Java — больше всего.
для GO приводится 1.75. То есть написать CRUD сервер на GO почти в 2 раза дольше, чем на Python? Это потому что на Python строк меньше будет?) Программирование - это не про синтаксис.
Складывается впечатление, что у автора еще до проведения анализа было своё мнение что лучше, он это и пытается донести
Чем больше объём кода, тем выше когнитивная нагрузка
Не согласен, лучше писать большое количество понятного и структурированого кода, краткость мало общего с понятностью имеет.
result = [x*2 for x in data if x%2==0]
even_numbers = []
for number in data:
if number % 2 == 0:
even_numbers.append(number * 2)что для вас понятнее? уверен код на 4 строчки более понятен
Возможно я плохо вчитался, но сложилось ощущение, что вы "топите" за Python. Я ничего против не имею, но стоит тогда так и писать "Считаю, что Python самый удобный и экономный язык".
Я не увидел агитации или какой-то матрицы выбора других языков, скорее увидел сравнения почему на Питон лучше/быстрее/выше, чем на языке Х.
Справедливости ради, перечитал пост и хочу дополнить свой коммент выше. Матрицу выбора увидел, но общее впечатление все равно про "продажу Python", извините.
Вы рассмотрели одну конкретную задачу, но реальный опыт эксплуатации состоит из разных задач, которые могут требовать разного от языка и программиста. Мысль, что разные языки хороши в разном - справедливая.
Но мир редко похож на лабораторию - полно легаси, сегодня одни задачи / завтра другие и т.д. Зоопарк языков и технологий несет свою боль. Добавление ИИ в разработку вносит свои коррективы.
Слишком много переменных, чтобы делать какие-то выводы в столь спорном вопросе - какой язык лучше/дешевле/т.д - вопрос слишком комплексный и зависит от ситуации "в момент решения"
я говорю про кейсы в самом начале. Смысл этого движеня: подсветить индустрии что нужно считать, про новые возможности Python, тк у многих запомнилась картина сильно медленного пайтоно без тайпинга и тп. Что бы не заносили Java для CMS или микросервисов.
На картинке с сокращениями там все проекты на Java. Совпадение?
Еще теперь когда спросят на чем делать будем новый проект, просто так Java не занесут у кого тут пригорело. Попросят обосновать.
Да нормально на Java можно микросервисы делать, при желании. На чем лучше и дешевле ещё вопрос (если считать вообще все расходы и специфику, а не только время собственно разработки).
Вы очень топите за Python и, как будто, для себя все решили. Я не против, но выводы неоднозначные и языковая тема сама по себе холиварная. Комментарии это только подтверждают.
Кстати, я так и не понял, какая именно статья Capers Jones имеется в виду.
В статье от 2017 года https://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf указывается, что затраты на одну функциональную точку для Java, Go и Python - одинаковые. У C#, кстати, чуть-чуть поменьше. Но там анализ из "общих принципов", без конкретной статистики.
Я не смог найти у Caper Jones статьи, где бы говорилось о преимуществах Python перед Go.
скажи, с чем не согласен? что на Java медленней разработка чем на Python? с зарплатами? со скоростью?
ну не согласен ты со скоростью разработки. посчитай ты по своей скорости. все равно не окупится. не будешь же ставить 1 к 1. плюс оплата выше. я подчеркиваю в статье в докладе - не согласны, посчитайте сами. по своим параметрам.
На Java скорость промышленной разработки с использованием существующей экосистемы как минимум не ниже, нежели на Python. Общее TCO скорее ниже, так как выше средний уровень разработчиков, выше качество библиотек и проще достигается высокое качество кода.
Оплата при равных навыках - примерно одинаковая во всех стеках (ну, разве что в Go сейчас заметно больше в РФ). Ключевое - "при равных навыках".
Ни одно из указанных исследований не показывает преимущество Python перед Java по скорости разработки, так как ни одно из них не измеряет скорость разработки хоть сколь-нибудь корректным образом. И это очевидно для любого, кто прочтет хотя бы одно исследование.
И, да, производительность таки важна. Так как число rps на сервис - это не число входящих запросов на систему. Вон, в Озоне больше 5 миллионов событий в секунду только на кафка, не считая всех прочих взаимодействий - и при этом число показываемых страниц около 1000 в секунду, да и то не всегда. И число активных клиентов заметно меньше 100 млн.
Статистика - это сложная штука и с ней надо обращаться аккуратно.
Про корректность скорости разработки я сразу говорю что сложно измерить, поэтому будет комплекс исследований. пощупаем слона с разных сторон закрытыми глазами.
Есть не одно исследование про оплату и Java там выше, это объективная реальность же. зачем с этим спорить то? у меня нет задачи убедить в чем то, особенно фанатиков. Твое право. Мне все равно на ЯП, подсвечиваю максимально объективно со ссылкой на исследования. Есть еще много исследований про ошибки на 1000 строк кода, когнитивную нагрузку = связь со скоростью разработки. Это я не до конца раскрываю тут, но вполне можно. А еще показываю на одном разрабе а не на двух или трех.
Цель статьи что бы сказали: обоснуй. Когда Java попытаются затащить. Все сокращения которые были в индустрии там Java..
На язык разработки должно быть все равно. Применять наиболее подходящий, а не тот который знаешь. Такие времена.
Исследование про оплату - никак не оценивает относительное качество кандидатов, так что его можно сразу выбросить, оно не дает никакой информации.
Все процитированные исследования про ЯП - не дают никакой информации про скорость разработки, у них просто дизайн такой, что к скорости разработки не имеет значения. А вот качество дефектов на функциональную точку у Питона выше (по той же статье Capers Jones, но это тоже не важно, так как это про абстрактный Питон, а не про реальную разработку.
Ты не привел никакой информации про сокращения из мира Java. В Сбере используется куча технологий, в PT вообще нет Java в стеке, насколько я знаю. Так что этот аргумент тоже не валидный.
Итого, у тебя нет ни одного валидного аргумента ни для одного твоего вывода. Увы.
Как будто бы все это уже и так раньше слышали.
Думаю стоило упомянуть, что в последнем питоне добавили возможность нормально использовать многопоточность, так что не настолько уже и выгоден переход для CPU bound на go
хорошая мысль конечно. на момент подготовки доклада 3.14 еще не было. Плюс про 3.14 должен быть подробный доклад на питерском Хайлоаде.
От "добавили возможность" до "разработчики научаться и библиотеки подтянутся" обычно проходит лет пять )
Эээ, а как многопоточность связана с CPU bound? Как раз наоборот, для CPU bound многопоточность не очень важна, там и с воркерами не сложно разрулить.
Спасибо за цифры. Я это подозревал, но количественно увидеть очень интересно. Жаль, нет котлина и С++. Тоже с коллегами не первый год спорим о целесообразности того или иного стека и возможности подбора стека под задачу. Пока, к сожалению рулит концепт "начальство умеет пользоваться молотком- собираем шкафы молотком".
цифры чудак выковыривал из 2023 года, потому что в 2024 жаве connection pool настроили и цифры уже ровно противоположные.
Это логично, аналитика, статистика всегда запаздывает. Но и разработчики не всегда последней версией пользуются.
Противоположное - это конечно интересно, но сравнительного анализа не видел.
Понятно, что есть цыгане, есть Мавроди, а есть статистика. Но лучше хоть такие цифры посмотреть, чем никакие. Дают повод подумать.
это не логично подсовывать читателю невалидные цифры из раунда 22, прекрасно осознавая, что все расчеты на таких цифрах - вранье (цифры из раунда 23 приводят к ровно противоположным выводам).
но вы можете кушать, что дают и много, много думать.
не правда. я дал инструменты, сказал: играйтесь, пишите свои цифры. открой, запиши и посмотри к чему они приводят. джава будет около Go максимум.
Плюс я оставил один бенчмарк, их много и все примерно будут в этом направлении. Цепляться за детали, несущественные нюансы и говорить вот вот оно.. ну такое. ничего не меняет ни раунд, ни скорость разработки. Сделай 2.. 1,5 подкрути производительность. все равно не выигрывает по стоимости.
правда в том, что ты пытаешься обмануть читателя осознанно подсовывая расчеты на не свежем тесте, хорошо осознавая, что и тест и рассуждения фуфло. цифры из более свежего теста ведут к противоположному выводу, поэтому ты взял не свежий тест и скрыл от читателя.
если бы перфоманс спринг был бы в самом деле на уровне мини фреймворков го, это был бы разгром го. то что делается парой аннотаций в спринге, на го потребует тонны кода и месяцы тестирования. со всеми вытекающими по стоимости.
очень скоро ии болванчики все изменят, нагенерят библиотек, обвязок и выиграет не тот язык где короче запись, а где больше рычажков тонкой настройки, возможности влезть в потроха и прочее.
Хм, какие инструменты ты дал? Некорректную финмодель, в которой ничего не учтено? Названия (не ссылки) на исследования, которые даже не прочитал и которых, возможно, вообще не существует? Ссылки на устаревшие бенчмарки?
Увы, но никакой информации ты не дал вообще (
Если бенчмарков много - приведи их список.
И что именно "все равно не выигрывает по скорости", можешь уточнить?
нет там противоположного. подставь и посмотри. инструрменты все дал, ставь какие угодно RPS и скорость разработки. не побьется бьется экономика, скорость разработки будет ниже, ФОТ выше. на дистанции 10 лет для одного разраба может быть. но нужно минимум два.
Экономика выбора: Python, Java, Go при разных RPS. Деньги или скорость?