В расте скомпилируется)

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

"все запросы асинхронные, все работало хорошо" - это всё понятно, тут же вопрос 1) как это скейлится на сложность 2) сколько обвязки требуется для асинхронных вызовов (по мне так дофига) 3) как при этом сделать shm DS без боли. В обычных кейсах одновремнно запущенные 100 потоков ос - вообще не проблема например, ни кто даже разбираться с этим не будет. А если это хайлоад, или хотя бы просто достаточно нагруженный сервис? или в амазоне работает, где ты цпу башляешь не хило? вот ты уверен например что твоя программа с асинк ревестами будет на 4х ядерном воркере работать в основном в 4 ядра? У меня на сишарпе проблема была не в том, что программа не работала вообще, а в том, что её оптимизация для конкурентных кейсов превращалась в ад

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

"все запросы асинхронные, все работало хорошо" - это всё понятно, тут же вопрос 1) как это скейлится на сложность 2) сколько обвязки требуется для асинхронных вызовов (по мне так дофига) 3) как при этом сделать shm DS без боли. В обычных кейсах одновремнно запущенные 100 потоков ос - вообще не проблема например, ни кто даже разбираться с этим не будет. А если это хайлоад, или хотя бы просто достаточно нагруженный сервис? или в амазоне работает, где ты цпу башляешь не хило? вот ты уверен например что твоя программа с асинк ревестами будет на 4х ядерном воркере работать в основном в 4 ядра? У меня на сишарпе проблема была не в том, что программа не работала вообще, а в том, что её оптимизация для конкурентных кейсов превращалась в ад

то есть в го ты просто делаешь функцию как есть, не пытаясь сделать её "асинхронной", а уж как её вызывать - ответственность  вызывающего кода, а не кода функции. Может быть уместно её синхронно вызвать, даже не смотря на то что она долгая. Не всегда же под каждый вызов отдельный тред создавать

> У меня на сишарпе проблема была не в том, что программа не работала вообще, а в том, что её оптимизация для конкурентных кейсов превращалась в ад

Хз, так же как и у всех. Если есть замороченные требования к выполнению - у сидристого был неплохой доклад на тему как сделать свой шедулер и все что хочешь на нем вертеть https://youtu.be/bHX7lwttrCA

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

Ну отдельные тредпулы для задач разных типов - это вполне себе легко на каких-нибудь котах/zio в той же скале, можно к тому же эти факты ещё и в системе типов отразить тем же FT

мы щас что-то более мейнстримное сравниваем. То что в скале все збс и идеально никто не спорит

если ты уберешь impl Future то нихуя не скомпилится

че

async fn foo() -> i32 { 42 }

#[tokio::main]
async fn main() {
 let answer_to_everything = foo().await;

 println!("Answer is {}", answer_to_everything)
}

Если ты уберешь асинк то код перестанет компилится

ну так в го горутины на таком же тредпуле выполняются, в чем разница?

а если await то нет

тогда у тебя Must_use залупится