🧩 Почему Databento не переписали feed-handler на Rust

Кратко:
- Контекст: реальный поток 14 млн сообщений/с и задержки <100 мкс. Требовались native-язык, простая параллельность и минимум общей памяти.
- Итог: для переписывания feed-handler выбрали C++23, а не Rust — из-за нескольких «больно на практике» паттернов.

Где Rust мешал именно под их кейс:
1) Повторное использование буфера
Хотели выделять буфер вне цикла и переиспользовать на итерациях без копий. Ссылки + времена жизни → конфликт с borrow-checker, хотя логически данные не переживают итерацию.

2) Самоссылочные структуры (self-referential structs)
Базовый паттерн «владение состоянием в объекте + подкомпоненты держат ссылки» в Rust упирается в модель заимствования. Обходные пути — RC/Arc или протаскивать ссылки аргументами — добавляют оверхед/шум. В C++ — просто порядок полей и правила перемещения/копирования.

3) Компиляционные дженерики
Шаблоны C++ гибче (partial specialization, fold-expr, constexpr). В Rust те же идеи требуют trait-интерфейсов и шаблонного «лесовоздства». На десятках версий структур получается много шаблонного кода или макросов.

Нет, это не «Rust плох»:
- У Databento уже много Rust в проде: кодеки DBN, realtime-шлюзы, клиентская библиотека. Инструменты cargo, диагностика компилятора и безопасность — огромный плюс.
- Но под данный «узкий» участок C++ дал:
кодо-реюз со старой базы, тонкий контроль ресурсов, гибкие шаблоны и прямая экспертиза команды.

Вывод:
- В их финтех-стеке оба языка уместны: Rust — где важны безопасность и современная экосистема, C++ — где критичны сам паттерн владения/памяти и совместимость с существующим кодом. Поле меняется: C++ получает compile-time reflection, Rust развивает Polonius — решения всегда прагматичны под задачу.

https://databento.com/blog/why-we-didnt-rewrite-our-feed-handler-in-rust