Ты сейчас про какой тезис? Про выбор языка - так там экономика вообще другая. Про выбор языка ради производительности - там тоже экономика вообще про другое.
Хм, какие инструменты ты дал? Некорректную финмодель, в которой ничего не учтено? Названия (не ссылки) на исследования, которые даже не прочитал и которых, возможно, вообще не существует? Ссылки на устаревшие бенчмарки? Увы, но никакой информации ты не дал вообще (
Если бенчмарков много - приведи их список. И что именно "все равно не выигрывает по скорости", можешь уточнить?
Во-первых, ты не привел ссылок (или каких-то уникальных параметров, по которым можно найти исследования). Во-вторых, те исследования, что удалось найти - не про "сравнение времени разработки", да и корректными их не назвать (
Хм, меньше всего строк получается на APL (впрочем, он действительно высокоуровневый). И вот на MUMPS гораздо компактнее выглядит код, нежели на SQL (но тут дело не в уровне).
Наверно и разрабатывать на этих языках быстрее (но нет...). Ну и когнитивная нагрузка от числа строк вообще не зависит, разумеется )
Исследование про оплату - никак не оценивает относительное качество кандидатов, так что его можно сразу выбросить, оно не дает никакой информации.
Все процитированные исследования про ЯП - не дают никакой информации про скорость разработки, у них просто дизайн такой, что к скорости разработки не имеет значения. А вот качество дефектов на функциональную точку у Питона выше (по той же статье Capers Jones, но это тоже не важно, так как это про абстрактный Питон, а не про реальную разработку.
Ты не привел никакой информации про сокращения из мира Java. В Сбере используется куча технологий, в PT вообще нет Java в стеке, насколько я знаю. Так что этот аргумент тоже не валидный.
Итого, у тебя нет ни одного валидного аргумента ни для одного твоего вывода. Увы.
И, да, производительность таки важна. Так как число rps на сервис - это не число входящих запросов на систему. Вон, в Озоне больше 5 миллионов событий в секунду только на кафка, не считая всех прочих взаимодействий - и при этом число показываемых страниц около 1000 в секунду, да и то не всегда. И число активных клиентов заметно меньше 100 млн. Статистика - это сложная штука и с ней надо обращаться аккуратно.
На Java скорость промышленной разработки с использованием существующей экосистемы как минимум не ниже, нежели на Python. Общее TCO скорее ниже, так как выше средний уровень разработчиков, выше качество библиотек и проще достигается высокое качество кода.
Оплата при равных навыках - примерно одинаковая во всех стеках (ну, разве что в Go сейчас заметно больше в РФ). Ключевое - "при равных навыках".
Ни одно из указанных исследований не показывает преимущество Python перед Java по скорости разработки, так как ни одно из них не измеряет скорость разработки хоть сколь-нибудь корректным образом. И это очевидно для любого, кто прочтет хотя бы одно исследование.
Ну, собственно на java делать микросервисы очень удобно, там для этого все есть. Другое дело, что на java можно и не делать микросервисы, а вот это более редкая возможность )
Расчеты как раз внимательно рассматривают. Но, увы, расчеты некорректные, начиная от исходных данных (придуманных автором и нигде не подтвержденных) и заканчивая непониманием базовых вещей в современной разработке (стоимость исправления дефектов, стоимость изменений, ориентированность на фреймворки и так далее).
Если бы статья была ровно про "производительность сервиса не так важна, как эффективность разработки" с указанием конкретных случаев, то вопросов к автору было бы гораздо меньше (ну, если бы с арифметикой не налажал бы). Но автор пытается сравнивать языки, не будучи достаточно компетентным в этом (т.е. просто не разбираясь ни в одном языке кроме Питона, да и в Питоне не очень).
Нет, в статье нет никаких ссылок на осмысленные международные исследования (о чем тебе много раз сказали). Более того, даже выводы из этих исследований сделать не получилось, так как со статистикой надо уметь работать. О чем тебе много раз и указывали.
Ни одно из этих исследований так не утверждает (так как, вообще говоря, нигде и не сравнивает скорость разработки на Java и на Python). Кстати, число багов в проектах на Python было (в 2014м) году заметно больше, чем в проектах на Java. Так что довод про "меньше кода - меньше ошибок" не верен (вернее, он может быть верен внутри одного языка и одного подхода к разработке, но для каждого случая надо проверять отдельно). Статистика - это опасная штука и для работы с ней нужны некоторые базовые компетенции.
Кстати, приведи статистику, по которой все сокращения (или, хотя бы, большинство) были на java?
Кажется (но надо копаться), что если бы включение VT давало такой выигрыш, то Spring+Kotlin давал бы заметный выигрыш от Spring+Java. Но, насколько я помню, это не так. Но про "фигня полная" согласен )
Ну, VirtualThread не всегда решают. Какое-нибудь решение на реактивном движке может оказаться не хуже, там в основном все зависит от эффективности nio. Но вообще да, TechEmpower - больше про предельную производительность, которую смогли выжать, к средней скорости продакшен кода имеет очень дальнее отношение (
Ты сейчас про какой тезис? Про выбор языка - так там экономика вообще другая. Про выбор языка ради производительности - там тоже экономика вообще про другое.
Хм, какие инструменты ты дал? Некорректную финмодель, в которой ничего не учтено? Названия (не ссылки) на исследования, которые даже не прочитал и которых, возможно, вообще не существует? Ссылки на устаревшие бенчмарки?
Увы, но никакой информации ты не дал вообще (
Если бенчмарков много - приведи их список.
И что именно "все равно не выигрывает по скорости", можешь уточнить?
Эээ, а как многопоточность связана с CPU bound? Как раз наоборот, для CPU bound многопоточность не очень важна, там и с воркерами не сложно разрулить.
Во-первых, ты не привел ссылок (или каких-то уникальных параметров, по которым можно найти исследования).
Во-вторых, те исследования, что удалось найти - не про "сравнение времени разработки", да и корректными их не назвать (
Хм, меньше всего строк получается на APL (впрочем, он действительно высокоуровневый).
И вот на MUMPS гораздо компактнее выглядит код, нежели на SQL (но тут дело не в уровне).
Наверно и разрабатывать на этих языках быстрее (но нет...).
Ну и когнитивная нагрузка от числа строк вообще не зависит, разумеется )
Исследование про оплату - никак не оценивает относительное качество кандидатов, так что его можно сразу выбросить, оно не дает никакой информации.
Все процитированные исследования про ЯП - не дают никакой информации про скорость разработки, у них просто дизайн такой, что к скорости разработки не имеет значения. А вот качество дефектов на функциональную точку у Питона выше (по той же статье Capers Jones, но это тоже не важно, так как это про абстрактный Питон, а не про реальную разработку.
Ты не привел никакой информации про сокращения из мира Java. В Сбере используется куча технологий, в PT вообще нет Java в стеке, насколько я знаю. Так что этот аргумент тоже не валидный.
Итого, у тебя нет ни одного валидного аргумента ни для одного твоего вывода. Увы.
От "добавили возможность" до "разработчики научаться и библиотеки подтянутся" обычно проходит лет пять )
И, да, производительность таки важна. Так как число rps на сервис - это не число входящих запросов на систему. Вон, в Озоне больше 5 миллионов событий в секунду только на кафка, не считая всех прочих взаимодействий - и при этом число показываемых страниц около 1000 в секунду, да и то не всегда. И число активных клиентов заметно меньше 100 млн.
Статистика - это сложная штука и с ней надо обращаться аккуратно.
На Java скорость промышленной разработки с использованием существующей экосистемы как минимум не ниже, нежели на Python. Общее TCO скорее ниже, так как выше средний уровень разработчиков, выше качество библиотек и проще достигается высокое качество кода.
Оплата при равных навыках - примерно одинаковая во всех стеках (ну, разве что в Go сейчас заметно больше в РФ). Ключевое - "при равных навыках".
Ни одно из указанных исследований не показывает преимущество Python перед Java по скорости разработки, так как ни одно из них не измеряет скорость разработки хоть сколь-нибудь корректным образом. И это очевидно для любого, кто прочтет хотя бы одно исследование.
Ну, собственно на java делать микросервисы очень удобно, там для этого все есть. Другое дело, что на java можно и не делать микросервисы, а вот это более редкая возможность )
Расчеты как раз внимательно рассматривают. Но, увы, расчеты некорректные, начиная от исходных данных (придуманных автором и нигде не подтвержденных) и заканчивая непониманием базовых вещей в современной разработке (стоимость исправления дефектов, стоимость изменений, ориентированность на фреймворки и так далее).
Если бы статья была ровно про "производительность сервиса не так важна, как эффективность разработки" с указанием конкретных случаев, то вопросов к автору было бы гораздо меньше (ну, если бы с арифметикой не налажал бы). Но автор пытается сравнивать языки, не будучи достаточно компетентным в этом (т.е. просто не разбираясь ни в одном языке кроме Питона, да и в Питоне не очень).
Кстати, я так и не понял, какая именно статья 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).
Кстати, число багов в проектах на Python было (в 2014м) году заметно больше, чем в проектах на Java. Так что довод про "меньше кода - меньше ошибок" не верен (вернее, он может быть верен внутри одного языка и одного подхода к разработке, но для каждого случая надо проверять отдельно).
Статистика - это опасная штука и для работы с ней нужны некоторые базовые компетенции.
Кстати, приведи статистику, по которой все сокращения (или, хотя бы, большинство) были на java?
Опять какие-то "исследования"? А что за исследования, можно ссылку хотя бы на одно корректное исследование, которое это подтверждает?
А можно привести ссылки на эти исследования, которые про "скорость" и про "баги"?
А то объективности пока как-то не заметно и близко.
Кажется (но надо копаться), что если бы включение VT давало такой выигрыш, то Spring+Kotlin давал бы заметный выигрыш от Spring+Java. Но, насколько я помню, это не так.
Но про "фигня полная" согласен )
Какие исследования показывают, что разработка на Python больше, чем на Java?
Из процитированных исследований - это ниоткуда не следует.
Ну, VirtualThread не всегда решают. Какое-нибудь решение на реактивном движке может оказаться не хуже, там в основном все зависит от эффективности nio.
Но вообще да, TechEmpower - больше про предельную производительность, которую смогли выжать, к средней скорости продакшен кода имеет очень дальнее отношение (