Async Rust Is The Bane Of My Existence | Prime Reacts

There are more Flutter state management libraries than there are databases.

Kotlin deals with code colouring in an interesting way: `inline` functions can transparently pass through the `async`-ness to a lambda without knowing about it ahead of time. It basically allows you to use something like `map` with an async function as long as you're inside of one.

One thing I've heard about but have not had the time to look up is "no I/O" crates. Crates where the library itself does no I/O, (takes only byte buffers/strings) and thus is sync/async agnostic. My guess is that it is not very good for state machine types of communication, but it does seem like a great workaround when it works.

Thanks for fixing my Rust FOMO.

In addition to improved crate-unification flexibility, another interesting idea might be to have macros that can output variants in different namespaces. I.e., instead of generating endpoint_sync and endpoint_async, more language support might allow rspotify::sync::endpoint and rspotify::async::endpoint. Being able to make distinctions via imports/using headers might be less cumbersome than peppering inline _[a]syncs everywhere.

"I have fearful concurrency 😂😂"

I solved this in a project internally where I work - the api produces a command struct that contains endpoint, body, headers etc with generics for body and response that must impl ser/de and then passed to either a sync or async client. It feels a little weird to use at first but it works reasonably well

i wish prime would read some blog post by the people who created rust async that explain the design decisions behind it...

I hear Prime in my head whenever I see or hear the word Tokyo, and if that isn't a sure sign I need therapy I don't know what is

0:45 Priceless The moment it *tings* in the brain that it's the right thing to tweet