Здравствуйте, LaptevVV, Вы писали:

LVV>В каждой новой конторе что-то не стандартное.

Это либо следствие древнего происхождения (и тогда это просто так не переписать), либо следствие специфических задач, под которые пришлось делать свой инструмент, возможно, заточенный не только под задачу, но и под конкретную систему (и тогда это точно на что-то из stdlib не переписать).

LVV>А в Go — из коробки и работает везде одинаково.

Одинаково тормознуто? То-то на пике хайпа вокруг Rust-а появлялись статьи о том, как узкие места Go на Rust-е расшивают.

LVV>Ну, забыли...
LVV>В запарке при сдаче релиза и такое бывает

Скорее всего, там была не запарка, а сознательное решение обеспечить сохранность итераторов при модификации, чтобы std::unordered_map мог быть прямой заменой std::map. В результате убили главное преимущество хэш-таблиц и получили рекомендацию не использовать std::unordered_map там, где требуется производительность.

Заиметь в стандарте какую-то реализацию reactor-а или proactor-а для сетевого IO, для которого будет аналогичная рекомендация "не использовать там, где требуется производительность"... Ну такое себе.

В прочем, пока еще есть шансы, что Networking TS следом за Executors TS до стандарта доедут. Не в C++23, так в C++26, ну или в C++29