И, да, производительность таки важна. Так как число 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 - больше про предельную производительность, которую смогли выжать, к средней скорости продакшен кода имеет очень дальнее отношение (
Антифрод - это, все-таки, внешний сервис для процессинга и его производительность сильно зависит от количества и сложности правил (если про rule-based антифрод). В этом тесте антифрод не использовался. А что именно интересует в реализации антифрода?
Так автор, похоже, скопировал документацию двухлетней давности, даже не попробовав посмотреть внутрь. А редактора у публикации, разумеется, не было. Впрочем, может быть, никакого "архитектора" тоже нет, просто маркетолог с Gigachat собрал пост, даже не попытавшись разобраться в содержании. А то текст не очень похож на текст от архитектора, даже в T1
Но можно написать свою библиотеку на тех же принципах, тогда миллисекунды будут вполне нормальной latency. Никакой особой магии нет, реализация библиотеки - 4-6 человекмесяцев сеньора.
А в чем отличие от шардирования через Citus? Там, вроде бы, примерно те же возможности, но запросы на чтение между шардами развиты несколько лучше, хотя балансировка шардов сделана чуть менее автоматической.
А чем простой select for update не проходит? Он же поставит блокировку, если ее нет. Впрочем, мне вообще не понятно, зачем при обработке платежа нужны подобные локи. Тут скорее проблема вообще всего процесса платежа, не нужны там ни мутексы, ни блокировки на БД.
От "добавили возможность" до "разработчики научаться и библиотеки подтянутся" обычно проходит лет пять )
И, да, производительность таки важна. Так как число 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 - больше про предельную производительность, которую смогли выжать, к средней скорости продакшен кода имеет очень дальнее отношение (
Антифрод - это, все-таки, внешний сервис для процессинга и его производительность сильно зависит от количества и сложности правил (если про rule-based антифрод). В этом тесте антифрод не использовался. А что именно интересует в реализации антифрода?
Так автор, похоже, скопировал документацию двухлетней давности, даже не попробовав посмотреть внутрь.
А редактора у публикации, разумеется, не было. Впрочем, может быть, никакого "архитектора" тоже нет, просто маркетолог с Gigachat собрал пост, даже не попытавшись разобраться в содержании. А то текст не очень похож на текст от архитектора, даже в T1
Но можно написать свою библиотеку на тех же принципах, тогда миллисекунды будут вполне нормальной latency.
Никакой особой магии нет, реализация библиотеки - 4-6 человекмесяцев сеньора.
Но при этом эти заметки будут в твоем Github или в чужом?
А в чем отличие от шардирования через Citus? Там, вроде бы, примерно те же возможности, но запросы на чтение между шардами развиты несколько лучше, хотя балансировка шардов сделана чуть менее автоматической.
А чем простой select for update не проходит? Он же поставит блокировку, если ее нет.
Впрочем, мне вообще не понятно, зачем при обработке платежа нужны подобные локи. Тут скорее проблема вообще всего процесса платежа, не нужны там ни мутексы, ни блокировки на БД.