Контейнеризация обычно не решает dependency hell, а переносит его на уровень image/runtime. Это хороший operational workaround, но не замена стеку, который изначально проще ставить и сопровождать
Отдельно стоит упомянуть что на Stan или Julia разработка такого статистического слоя, скорее всего, шла бы заметно быстрее. Особенно на этапе прототипирования и перебора моделей.
Но наши бенчи показывают, что итоговый выбор архитектуры всё равно даёт выигрыш по скорости даже относительно Stan, который де-факто считается индустриальным стандартом для статистических вычислений и по идее должен был бы нас обыгрывать. Поэтому здесь компромисс был такой: медленнее разработка, зато быстрее и проще в эксплуатации конечный вычислительный контур
Да, архитектура тут важнее самого названия языка. Но стек тоже имеет значение.
В R/Julia обычно вместе с “решением” приезжает отдельный рантайм, пачка пакетов и системных зависимостей. В итоге вопрос уже не только в вычислениях, а ещё и в установке, совместимости и сопровождении.
У нас идея была не просто ускорить hot path, а сделать инструмент, который ставится одной командой без dependency hell и нормально живёт в production. Так что здесь скорее связка: правильная архитектура + стек, который не тащит за собой лишний зоопарк
Не, смысл не в том, что Rust хороший, а остальные языки мусор. Просто для таких задач он даёт очень сильный practical mix: безопасная работа с памятью без типичной C/C++ боли, высокая производительность за счёт нативной компиляции и нормальной работы в hot path, плюс заметно меньше dependency hell при сборке и переносе проекта. И для нас это особенно важно, потому что в HEP люди всё равно привыкли работать через Python-харнесы, ноутбуки и привычный analysis workflow, а Rust тут хорошо ложится как backend для тяжёлого вычислительного ядра, не ломая этот привычный слой
Information
Rating
4,665-th
Registered
Activity
Specialization
Фулстек разработчик, Архитектор программного обеспечения
Контейнеризация обычно не решает dependency hell, а переносит его на уровень image/runtime. Это хороший operational workaround, но не замена стеку, который изначально проще ставить и сопровождать
Отдельно стоит упомянуть что на Stan или Julia разработка такого статистического слоя, скорее всего, шла бы заметно быстрее. Особенно на этапе прототипирования и перебора моделей.
Но наши бенчи показывают, что итоговый выбор архитектуры всё равно даёт выигрыш по скорости даже относительно Stan, который де-факто считается индустриальным стандартом для статистических вычислений и по идее должен был бы нас обыгрывать. Поэтому здесь компромисс был такой: медленнее разработка, зато быстрее и проще в эксплуатации конечный вычислительный контур
Да, архитектура тут важнее самого названия языка. Но стек тоже имеет значение.
В R/Julia обычно вместе с “решением” приезжает отдельный рантайм, пачка пакетов и системных зависимостей. В итоге вопрос уже не только в вычислениях, а ещё и в установке, совместимости и сопровождении.
У нас идея была не просто ускорить hot path, а сделать инструмент, который ставится одной командой без dependency hell и нормально живёт в production. Так что здесь скорее связка: правильная архитектура + стек, который не тащит за собой лишний зоопарк
Не, смысл не в том, что Rust хороший, а остальные языки мусор. Просто для таких задач он даёт очень сильный practical mix: безопасная работа с памятью без типичной C/C++ боли, высокая производительность за счёт нативной компиляции и нормальной работы в hot path, плюс заметно меньше dependency hell при сборке и переносе проекта. И для нас это особенно важно, потому что в HEP люди всё равно привыкли работать через Python-харнесы, ноутбуки и привычный analysis workflow, а Rust тут хорошо ложится как backend для тяжёлого вычислительного ядра, не ломая этот привычный слой