Пока меньше миллиона - не парься

const fn нормальный завезли, наконец-то!

Пофиксили баги из 1.45.1-3?)

buffer_unordered, может?

Коллеги, кто-нибудь использует async-std в проде? Решил для нового проекта попробовать его (т.к. по обещаниям разработчиков в будущем выглядит перспективнее чем tokio, по крайней мере мне так показалось), но столкнулся с небольшими трудностями. Не собирается проект под виндой. Под линем всё собирается (и даже почему-то работает), а под шиндовс пришет что линкер не может найти функции epoll_* - не понятно, зачем он вообще их пытается найти, epoll же не виндовая тема. Наверно у меня что-то фундаментально не так, хотя ничего необычного я не делал. Беглым гуглением не удалось найти похожих проблем, или вообще упоминаний что под виндой оно не работает. Кто-то сталкивался? Каких-то фич, похожих по названию на poll тоже у крейта не обнаружил.

Пробовал собрать этот же проект с tokio - всё прекрасно собирается и под линуксом, и под шиндовс.

Вообще, кто-то может покритиковать выбор async-std, может кто-то уже более детально пробовал и async-std и tokio, и может что-то рассказать чего я не знаю?

Непонятно, зачем брать async-std, если у тебя нет проблем с tokio.

Может у тебя там что-то сломалось? smol под виндой использует wepoll.

Это не конструктивный ответ.

Ну и да, токио получше пока что.

Ну почти наверняка сломалось. Вопрос - что и как починить. Куда копать пока идей больше нет.

А есть какая-то конкретика? Чем именно получше?

("чем async-sts", ага)

Под его рантайм либ много понаписано. reqwest, hyper — всё на токио.

Ну и AsyncWrite там на BufMut, что позволяет удобно работать с uninit памятью.

Валидно. Что-то ещё? (допустим, с либами вопрос не стоит вроде бы)

Токио старше и стабильнее

Насчет стабильности - async-std недавно перешёл на smol, и с этим в некоторых задачах производительность упала до нуля

уже ушел со смола, вроде как.

У токио есть минус - для того, чтобы он работал с другими либами типа futures, иногда необходимы обертки, которые иногда не zero-cost.