Контейнеризация обычно не решает 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
Does not participate
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 для тяжёлого вычислительного ядра, не ломая этот привычный слой