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.

Erlang developers can't comprehend

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.

I'm going to spend a few months learning how to write a database, then spend the rest of the year producing databases in different languages. There must be more. MORE.

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