Comments 36
А тем временем по поводу async-std vs tokio во всю не очень понятная драма развивается.
https://www.reddit.com/r/rust/comments/dse875/2020_be_open_and_friendly/
Причем эмоции прямо зашкаливают
Но вообще мне в этой истории непонятны нападки на async-std, что они создают фрагментацию и страдают NIH синдромом. В конце концов их видение очень сильно отличается от видения Tokio и так с ходу не очевидно, чье же видение в реальности лучше.
И кажется мне, что в таких делах все точки над i расставит время и реальные истории использования.
В конце концов это не первая и не последняя история с войной форков в опенсорсе и многие прошлые войны в результате привели к созданию очень годных продуктов.
Просто идентифицировал пострадавшего.
Кстати на реддите модераторы прикрывают этот флейм.
This thread has been locked by the moderators of r/rustИ блочат (похоже что и на гите o_O) всех комментирующих. Мило =)
github.com/withoutboats/romio/pull/106
humbug с помощью ряда верных падаванов попытался пропиарить tokio как альтернативу async-std в некоем богом забытом проекте, некоторые участники этого проекта (в том числе его автор) несколько удивились явному форсингу рядового коммита по правке документации, и тут заверте…
Там автор репозитория всех коментирующих занес в свой личный блок лист вместо лока дискуссии и как я понял некоторые из-за этого стали забанены в некоторых организациях которыми он владел, вроде http-rs и другие.
Не то чтобы отказались совсем, через GAT можно делать HKT как я понимаю. Но вот пока GAT не осилили
Никак. Но добиться чего-то "пахнущего как" можно.
Последние потуги описаны тут: varkor's blog: Idiomatic monads in Rust.
Вообще тут важно просто не поддаваться эмоциям, а то так и получается, кто-то сделал что-то исходя из совершенно травоядных мотивов, а кто-то интерпретировал его поведение как токсичное и начал уже со своей стороны отраву разбрасывать.
Лучше наверное в таких случаях постараться проанализировать, возможно в действиях, вызвавших бурную реакцию и не было ничего токсичного изначально.
Я забросил писать русскоязычные хабро-ежемесячники про раст, зато, если кому интересно, пару месяцев назад стал писать официальные ежемесячники чисто про ржавую разработку игр — https://rust-gamedev.github.io — только что вот октябрьский выпуск опубликован. :)
let af = get_a_async();
let bf = get_b_async();
let a = af.await;
let b = bf.await;
Сам async/.await тут ни при чём. Просто в Rust и без async/.await модель исполнения futures сделана poll-based, а не push-based как к этому все привыкли в других языка.
Это был осознанный выбор и этому есть ряд причин, которые неплохо описаны в этим статьях:
Что же касается "невозможностей", то таких нет. Всё возможно, просто выполняется немного иначе, нежели привыкли, и с оглядкой на poll-based ленивость футур. Конкретно ваш пример решается следующим образом:
let (a, b) = futures::join!(get_a_async(), get_b_async()).await;
А почему join макрос? Разве функцией он не реализуется?
В Rust нет variadic function arguments, потому существует несколько вариантов join'а в зависимости от кол-ва аргументов: join, join3, join4,… join_all.
Как вы догадываетесь, это обилие было бы не слишком приятно видеть в коде, потому эти функции сверху прикрыты макросом join!, который при разворачивании автоматически использует необходимую функцию.
Собственно, использование макроса для того, чтобы предоставить возможности variadic arguments — достаточно стандартный приём в Rust и применяется много где.
Спасибо, понятно. Я так понимаю, что variadic generics есть в долгосрочных планах и они заменят в будущем такого рода использование макросов?
Я ничего не слышал про планы на variadic generics. В плане языковых фич в данный момент есть планы на const generics, GATs (generic associated types) и specialization.
Но, даже если бы variadic generics были, я сомневаюсь, чтобы они помогли в данной ситуации, ведь они оперируют на уровне сигнатуры типов, а не сигнатуры аргументов функции. Вещи, конечно же, связанные, но далеко не одно и то же.
А в чём проблема использования макросов? ИМХО, одна из положительных сторон Rust — это как раз first-class citizen макросы. Они очень гибки и очень помогают для решения часто самых неожиданных задач, гораздо более чаще, нежели затыкают "дыры" выразительности языковых конструкций. После Rust их часто очень не хватает в других языках.
Я ничего не слышал про планы на variadic generics.Я просто загуглил и нашел такой pre-RFC. Возможно, дальше этого дело не пошло, я не в курсе.
Но, даже если бы variadic generics были, я сомневаюсь, чтобы они помогли в данной ситуации, ведь они оперируют на уровне сигнатуры типов, а не сигнатуры аргументов функции.Ну если variadic generics случатся, то написать функцию принимающую переменное число аргументов не должно быть проблемой (сужу по опыту C++).
А в чём проблема использования макросов?Наверное, в использовании нет проблем (у меня нет практического опыта на Rust-е). Я думал про написание такого макроса — оперировать потоком токенов должно быть сложнее, чем написание generic функции.
Я думал про написание такого макроса — оперировать потоком токенов должно быть сложнее, чем написание generic функции.
С этим в целом глупо спорить. Но хорошая новость в том, что в этом Rust тоже достаточно не плох:
macro_rules! map {
($( $key:expr => $val:expr ),*) => {{
let mut hm = HashMap::new();
$( hm.insert($key, $val); )*
hm
}};
}
let number_names = map! {
1 => "one",
2 => "two"
};Как видим, не ядерная физика в тривиальных случаях =)
В остальных будет больнее, да.
Да и эта * похожа на… в си плюс плюс, но когда надо целый класс определить с variadic, то как хорошо IDE умеет работать с кодом внутри макроса?
Пока что с IDE, и в особенности их работой с макросами, всё далеко не сладко, увы.
Им и живы =)
Но там тоже все ещё много работы в плане макросов. Декларативные раскрываются хорошо и дают нормальный автокомплит, но вот редактирование синтаксиса внутри декларативного макроса — только руками. У процедурных все не очень в плане раскрытия, но вот их написание вполне ОК, так как это обычный код работающий с токенами и AST.
А кириллические / не латинские имена переменных и функций разрешили использовать? В предыдущей версии Rust обещали разрешить "потом" :(
Пока нет. За прогрессом можно следить тут: https://github.com/rust-lang/rust/issues/55467
Выпуск Rust 1.39.0: async/await, аттрибуты для параметров функций, новые константные функции