4 ms·
Any sign of async functions in traits without the macro? One kindah would expect first class async support for web services and honestly something like Swift pr
by qaq 3y ago
Any sign of async functions in traits without the macro? One kindah would expect first class async support for web services and honestly something like Swift prob. has better balance between usability and speed for most web services.
- hgomersall 3y agoYeah, it's expected this year: https://blog.rust-lang.org/inside-rust/2023/05/03/stabilizing-async-fn-in-trait.html https://blog.rust-lang.org/inside-rust/2023/05/03/stabilizin...
- qaq 3y agoasync fn do_health_check_par<HC>(hc: HC) where HC: HealthCheck + Send + 'static, HC::check(): Send, // <-- associated return type { tokio::task::spawn(async move { if !hc.check().await { log_health_check_failure().await; } }); } Hmm I think for 95% of the people sticking to something like Swift would work out better for them
- hgomersall 3y agoAre you saying 95% of use cases require spawning new tasks within the trait implementation based on argument futures? Or are you making a more general comment about rust generics? The MVP looks about as clean as I could hope for most use cases.
- qaq 3y agoI am saying that in web services you will frequently use async functions that look like async fn do_blah(db_repo: impl DBRepo ...) {...} and are executed on async-std or Tokio
- hgomersall 3y agoThat will work. It only needs the additional bounds if you want to spawn that as a new task.
- qaq 3y agoso if I am doing async calls on DBRepo inside that function they can not be moved to a different thread by a runtime like tokio?
- jen20 3y agoOne would typically not spawn those - as I understand it you need the type constraints if calling “tokio::spawn” (or some equivalent) but not if simply calling an async function in the same task.
- insanitybit 3y agoWhy is the macro not a solution?
- qaq 3y agodon't you have like extra heap allocation per call with code that macro expands to?