Rust async в трейтах — наконец-то или всё ещё боль?

[async2025]

Начал новый проект на Rust 1.85, решил обойтись без async-trait крейта — всё-таки async fn in traits уже стабилизировано. Написал базовый интерфейс репозитория с async методами, всё компилируется. Но наткнулся на стену когда попробовал сделать Vec<Box<dyn Repository>> — компилятор говорит что трейт не object-safe. Понял что dyn Trait с async методами до сих пор не работает. Что люди делают в таких случаях? Возвращаться на async-trait?

[mstrbates]

Именно это и есть текущее ограничение: статическая диспетчеризация через generics работает отлично, динамическая через dyn — пока нет. Решений несколько. Первое — продолжать использовать async-trait крейт, он добавляет Box::pin автоматически и делает трейт object-safe, цена — аллокация на каждый вызов. Второе — нагородить вручную: возвращать Pin<Box<dyn Future<Output=...> + Send>> из трейта явно, без async fn синтаксиса. Третье — переосмыслить архитектуру и не использовать dyn там где не нужно.

[tankard]

@mstrbates, Мы в своём проекте сделали enum dispatch вместо dyn. Вместо Box<dyn Repository> у нас Repository enum с вариантами PostgresRepo, MockRepo и т.д., и матч внутри. Код стал более многословным, зато нулевые аллокации на диспетчеризацию и компилятор видит все ветки. Для небольшого числа реализаций это вполне нормально.

[jownby]

@async2025, Нужно различать два разных сценария. Если пишешь библиотеку — там dyn нужен чтобы пользователи могли подставлять свои реализации. Там async-trait ещё оправдан. Если пишешь приложение — там generics почти всегда лучше, и вся эта боль с dyn просто не нужна. Большинство людей страдает от dyn в приложениях по привычке из Java/C# где интерфейсы обычно динамические.

[regex4]

@mstrbates, Стоит следить за RFC про dyn-compatible async traits — там идёт работа, но это сложная проблема из-за размеров Future разных реализаций. Interim решение через type erasure обсуждается. Скорее всего появится в 1.88-1.90 если не будет сюрпризов. А пока — async-trait для dyn, нативный синтаксис для static dispatch, и это вполне рабочая комбинация.

[slypmp]

@async2025, Опыт реального проекта: переписали сервис авторизации на Rust 1.85 без async-trait крейта там где смогли. Получилось убрать его из ~70% кода. Оставшиеся 30% — это именно dynamic dispatch для плагинов. Производительность под нагрузкой выросла, но незначительно — у нас всё равно IO-bound. Зато время компиляции немного упало что приятно.

[redislover]

Раз уже сидишь на нативных async fn in traits — заложись на следующие грабли заранее: возвращаемые футуры по умолчанию не обязаны быть Send, и это вылезет не при компиляции трейта, а позже, когда отдашь вызов в tokio::spawn. Лечится крейтом trait-variant, который сама команда Rust и рекомендует: макрос генерит Send-вариант трейта. Лучше прикрутить сейчас, пока интерфейс репозитория не расползся по всему коду.

[bruce01]

@tankard, enum dispatch — рабочая тема, и многословность лечится крейтом enum_dispatch: матчи по вариантам он генерит сам. Единственное настоящее ограничение — закрытый набор реализаций: плагин из чужого крейта в ваш enum не добавишь. Но для репозиториев внутри приложения, где реализаций две-три и все свои, это даже плюс — добавил вариант, и компилятор заставил обработать его везде.

[Version]

@jownby, про привычку из Java соглашусь только наполовину. В больших приложениях за dyn идут не только по инерции: generics мономорфизируются, и когда репозиторий прорастает через десяток слоёв, время компиляции и размер бинаря растут вполне ощутимо. Box<dyn ...> на границе модуля иногда осознанный размен рантайм-цены на вменяемые инкременталки, а не карго-культ.