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.

love the way PapaPrime reads, flip-flopping between "human being" and "Microsoft Sam". Really knows what his viewers are looking for. Keeps everyone on their toes, himself included.

Thanks for fixing my Rust FOMO.

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.

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 have fearful concurrency 😂😂"

Oh, regarding sync/async code variations, I think a look on the "generic keywords innitiative" post on Rust-lang blog would be a good read, it is a pretty interesting and I would say novel idea of bringing compiler-generated variations for sync/async code (and other types of discriminative keywords as well).

Erlang developers can't comprehend

Correct me if I'm wrong, but I don't agree that you should default to making a sync version of the library and let the library's consumers deal with calling it asynchronously, because as soon as you have a sync function, there's no other option for the caller than to have an entire thread blocking on the operation until it finishes. Meanwhile if you just use async functions, the caller can simply use something like smol::block_on to turn it into a synchronous call. Especially with something like the http-client agnostic implementation I feel like that shouldn't be an issue at all.

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

write a base sync library then extend it with an async library to add the functionality to the base. if you don't need async then you use only the base. if you need async then you use both libraries.

I couldn't imagine spending nine months trying to implement a feature no one was asking for. I'm sure he learned a lot, though!

I much prefer Go async-all of the library code is synchronous, and the caller can call your function in a goroutine if they want async

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

31:56 Mogueno would like a role model time scale to compare himself to. In my case i started typing in pop sci magazine listings in QBASIC in 1996, made my own local website in HTML + JS in 1997, made a QuakeC mod in 1998, learned Iptscrae and PHP in 1999, Java in 2000, C++ in 2001, etc.

I would build the sync version as a core package and 2 more packages. One of them would be a tokio wrapper and the other would be a reqwest package. That way the user can use the meta package they need and you won't duplicate your code.

Feels like answering the feature request with "No, what would be the benefit?" would save everyone a lot of pain

you know, if prime has trouble with rust, I don't feel so bad anymore about barely getting started

11:14 but since the code itself is synchronous(that's why we are using the blocking version), B can't get called before A is done, right? so how is that a problem?

1:13 Appreciate all the THAN*s in chat and Prime ignoring them like a chad.

The idea that people have so many active requests to spotify that they need them all freeing threads is wild. I bet maybe _one_ of their users is really in this boat.

The reason Go is easy is because it is a garbage collected language. That gives a lot of language simplicity and safety automatically, but also a serious performance cost. The point of Rust is extreme efficiency and real safety at the same time, but a bit more difficult indeed. Of course I would like it when they could do something to solve the color issue at Rust language level, but then I also hope they consider a way to compile actual sync functions next to the async ones, and not functions that just look like they are sync while they are silently still state machines with a poll function. They are also doing something in the Zig language with colorless functions, but if I am right there they do not eliminate a state machine either in the sync usage case.

"adding a new endpoint or modifying it meant writing or removing everything twice" WET (write everything twice) peoples dream

Instead of adding a _sync suffix it could add a sync (or async) submodule. Would be nicer, IMO.

I have the same problem with one of my C# libraries. It is a custom transaction ledger database. It can be embedded to a game for storing the economy of a game or can be used as a standalone server for processing transactions in an cryptocurrency market vs... It runs super-fast as a single server and for multiple server scenarios it supports distribution of records and clustering. It has locking mechanisms for handling transactions involving accounts distributed across different servers, and this creates a requirement for whole system to be async. I have two implementation of it right now. First one is an async implementation supports all kind of distributed usages. The other one is a synchronous implementation that has also heavy heap usage optimization. I wish I could convert one into another as a part of build process or abstract it somehow.

0:31 lol i felt that hit so hard

This feels like a macro situation If this was c I would redefine async and await to an empty string then compile twice

Looking up the way Zig tries to solve it is quite interesting.

Javascript has the advantage of the promise API. As long as your top level function is async (or you .then() the promise) you can use any number of sync functions in between your other async (or promise returning) function.

Maybe a crate such as rspotify is... stupid? How long should it take me as someone using Spotify web api to produce an access layer suitable for my purpose? In compliance with my choice of async behavior? Or maybe the crate should focus on defining the request body and how it's serialized, and not on sending an http request?

You know what Kotlin has? Built-in singletons ;)

It gets even worse if you add gui and api to the mix but its always solvable so not to bad. The fun part about rust is you have to invent or combine architectures for a lot of problems. I also thought using listeners would solve this problem on my hobby project 😂 😂 . There is always a simple way in rust in the end though, just need to invent it 😂

Are there still people who do not get Async Rust != Tokio? This reminds me of "Avoiding async entirely" on the wg-async repo

"async was a mistake" Just gifted you a great tweet :)

If I were the maintainer, I'd either do only sync, like prime, or make sync and the async version being a call to the sync version with hardware threads. But I'd only do the latter if there were a lot of demand for. The engineering effort to make it work would be humongous.

What switches are you using on your keyboard? They sound wonderful

Went through something similar with a python project last year: I made a package that includes a DB model system, query builder, an ORM, a migration management tool, code generators, and a bundled coupling to the standard sqlite library (all opt-in features); the first feedback I got was "can you use it async?" So I started by converting it to async and made the bundled coupling use an async version of sqlite, then I tried wrapping the async stuff to use it synchronously. The async overhead for using sqlite was just too extreme -- sync writes took 90µs on average anyway and sync reads were like 20µs, while the async overhead added another 30-50µs to each -- so I ended up with duplicated code. The guy who requested it said after I had spent over a week on the async implementation that he wasn't going to use it. Oof.

I really dislike asyc-await since I feel it hides too much, requires too much, and gives too little benefit. I much prefer boost::fiber like stackful fibers, or Erlang-like actors, where the former mostly leaves your sync code untouched, and only requires changes at the "borders"/"edges" of code / control flow, while the latter encourages less coupling, and can potentially result in less memory waste than callbacks / async-await.

The tokio way to do this without the global mutex is to just use an actor/daemon that wraps the API instead of a mutex. Have the thread that initiate the request send a message to the actor and block until it gets a response, just like you would in Erlang. The actor can use async code internally, and certainly no Arc , you just clone channel producers and pass a Sender, while for the return value tokio::sync specifically provides oneshot channels. When all the producers are dropped the channel closes and the daemon dies as expected. It's a bit boilerplate heavy to write message impls depending on how wide your API, but if you have a wide API that needs to be converted to sync, then that is your actual problem imho.

Why not build it sync and offer an async wrapper library?

I'm actually writing some software that uses this library... the maybe-async wrapper is a complete pain. Especially because I tried to use it with async and sync in the same codebase. (conditionally compiling webassembly fml). I ended up abandoning it completely and just using their data model sub-crate and making the HTTP requests myself. Quite obscure library imo, interesting to see if pop up on my youtube feed.

Does any language do the opposite of async/await? As in, all methods are synchronous, but you can background them. E.g in a method, you may want to make two simultaneous calls to some external API. So you background them, then stop and wait for both. I’m meaning language support, not just Task.WaitAll(tasks). I think the closest may be channels in Go????

Prime, will you read "Let futures be futures" published 3 days ago by withoutboats? It seems relevant.

if you don't await multiple asyncs at once, or do some random concurrency thing in your code (start an async coroutine, continue some task, then await that coroutine), why would you want to make the whole thing async even

Thank god I’m not the only one who feels this way about databases 😂

Wait I'm a bit confused. Why does the library need to have async? I thought that it had async because it had actions that could be waited, meaning that running it concurrently would be more efficient. Why create an async implementation if there is no IO operations that require waiting?

There should be a minimal Future "runtime" that only supports block_on, just for cases like this. Wouldn't it be almost trivial to implement? Edit: I did it. It was trivial to write, but I haven't tested it. Published as its_ok_to_be_block_on crate.

The coloring problem is an interesting one. I'm used to using languages like elixir which completely sidestep this problem by putting everything into a process instead. Go has a similar concurrency model because you have multiple call stacks which you can switch between via go routines. I believe Ruby also side steps this problem with its fibers and so does C#.

The good old fashioned copy and paste code 😂

Somebody was drinking too much Kooool-Aid

singletons are the king of all antipatterns

what happens if you create two crates one async and one sync both just have the same single codebase that uses the maybe async crate and separate flag values for the maybe async.

that feel when not using a mutex cause thread dependent message queues are nice..

is it just me or does having do_thing() and do_thing_sync() not seem like that big of a deal?? Like, just do the fixed version of maybe_async, but only append a suffix to the sync versions. Literally the first thing I would have tried is making a macro to do that, lol.

Re: colored functions, this is exactly what react did with hooks...

Isn't having tokio as a dependency similar to using golang, in terms of runtime? I'd guess that's exactly how sync requests work in go.

The worst part is, the whole reason for async to exist is literally just optimization. I honestly believe just forking and joining threads is much simpler and easier, obviously that's not an option for JS, but everywhere else you can just fork/join threads. But, of course, the issue with doing that is the thread startup time and memory overhead... but then you can sidestep those issues by running green threads on top of a thread pool (ala Go) - I don't understand why async/await won instead of the Go model (other than - because JS did it)

just dont support sync and if someone wants to use it sync just let them use the futures library to force it. im pretty sure i dont have a single project withought tokio

Why not provide a default async runtime but allow the library user to provide one as well? If we’re being real, why would you expect an web API library to not be async? It just fundamentally is, it’s web requests. Either slap on a tokio main, or some other macro that simply adds block_on() to every async call.

Arangodb has been around for a long time. It's a pretty great graph db.

arc , as a web dev, this shit is hell

love this article, actually very educational

so this is where the Primeagen tweets come from 😆

I love the idea of lunatic, which is a wasm runtime mimicking the process architecture of erlang. Every process is a wasm thread which is cheap, and scheduling is cooperative like go, where blocking syscalls are substituted by the runtime, resulting in uncolored async code! Too bad its dead

Maybe it's my inner functional bro speaking but you could just pass in a function that executes the request, or just make the library a request builder instead of a request executor, and leave it to the caller, or just have a single execute and execute async function that takes a built request and uses a generic type for the response Or just make people generate their own client libraries with grpc/openapi/asyncapi/etc

All I think about this is : oh god I just hope async never actually reach Zig, I don't want to deal with this nonsense xD

couldn't you write a procedural macro that removes asyncs and awaits to codegen the sync tests.

I'm getting dejavu, did I watch this on stream or is it a reupload

Should have used Elixir, amirite

Writing a sync library makes it more or less unusable in a async context tho if a application is IO bound + perf sensitive. Not great for a API wrapper I would say (sync inherently limits number of concurrent calls to number of OS threads, async does not).

You should read "Let futures be futures."

honestly the biggest problem with async rust is that nobody talks ab it! i see so many tutorials on the rust fundamentals and even advanced rust, but the second i look for aync rust the only thing i see (besides the official documentation) is just people complaining about async rust! dont get me wrong the documentation helps but i wanna see async rust in action. i wanna see how developers actually USE async rust. if anyone could help out and tell me where i can find resources on async rust then that would be appreciated!

What I am hearing here is don't support blocking interfaces. If a library requires async for performance, then you should embrace async/await.

mean girls was lit

Tom could have solved this. Definite skill issue

This whole article is a lesson to just say no.

The most obvious thing was maybe don't implement a useless feature request? Web API's are async, if an end user wants a blocking API it can wrap it themselves.

Honestly, the explanation for colored functions made no sense to me with red/blue but makes perfect sense with sync/async. Sometimes, it's not a good idea to try to popularize a concept. That might have helped other people to understand though.

Just wrap everything in M4 and use macros to make each version, just the build script informs how each file expands. /j

So asyc code is contagious? I might try to just stick to threads and channels then haha, async is mostly for functions that might have waiting in them and should give way right?

This could all become fixed when `Effect Generics` land in Rust :)

9:10 I don't think people realize how many globals are used in the software they are using... and globals aren't the devil. They don't realistically affect performance, and while they should be avoided for cases where they don't make sense in order to keep the code clean and sustainable, if you think your only option is to use a global, it's probably correct.

Even C++ has coroutines. Rust catch up!

I started tp think lately that there is no "uncolored function" at all in any language, you will be compromising yourself either with a runtime or with some distinction between the "worlds", it is this way for Rust, Go, C#, Kotlin, all languages.

There is a new Mean Girls now. Sigh I'm sad and old.

Singleton pattern is globals with extra steps.

Moral of the story: Don't throw yourself on the sword in pursuit of correctness

Is this whole async business not another example of our attitude to always think and work on the wrong abstraction level? And not matter at which level we do that, we don't think it through and we don't finish the job. The problem with async is that some parts of our technology are operating synchronously (CPUs) and other parts are operating asynchronously (IO). The former uses instruction pointers and stacks while the latter uses interrupts. This did not change in half a century. When async-IO was introduced in UNIX, this was a misnomer, because IO was already asynchronous. Async-IO just allowed software to not to have to wait for asynchronous IO to complete and thus pass CPU cycles to other processes or threads. Or in other words, it makes it possible not to have to rely on the operating system abstraction of synchronicity (processes or threads) and let the process or thread use its own (e.g. the programming language running stuff in the thread or process). Why can you not use await f() in a synchronous method? In essence because it's to hard for language implementers to support that feature. They leave it up to application developers to solve the problem, something that they can't really do, given that they are in a much worse position to solve that difficult problem. Languages like C do not have async or await (not when last I looked). They're honest and don't even try to fix the problem, but they also don't add to it by providing a half baked solution that only works if you only do sync or async, which you actually can't really do unless you work in a very confined context. As a consequence you have to understand how you can and want to handle IO. As software running in a thread or process, you have to talk to the OS to do that and thus you need to understand how that works. You have a plethora of options available, but you also have to handle just as many buggy implementations. You need to understand concurrency and learn how to not deadlock, what is thread safe and how to semaphore. I keep wanting to learn Rust, but whenever I make an attempt to look at it more closely, I come across something that makes Rust extremely unattractive. All the good stuff or at least most of it, I know from other languages. There is no feature that I know of, that other languages did not yet come up with. But Rust collected a whole lot of the good stuff. That should make it really sexy. But to me it seems as if it also collected all the bad stuff from all over the place. The syntax from Perl. The attitude from SCO (in the project). Having to struggle with async/await and how to handle it from sync code as in this example is a native JavaScript problem. There is no async code. Code is always synchronous, IO is asynchronous.

All the negative things will be said about Go however the language has made the world a better place concerning simplicity and speed. Rust is for the PHDs and Nerds. I am not one of them and I gladly accept I have skill issues with it. I find it too bloated and just complex. Looking forward to Zig 1.0.

You have to be a morón to be using Rust!

Is this still an issue with rust?

I don't want to hurt anyone's feelings but this is where javascript would make sense :D

What I want to know is why on god's green earth would you want to make a Spotify API wrapper async? There is literally nothing to be gained. Absolutely 0.

async is sync if you never spawn tasks on your runtime 🤔

When Prime reads an article, it'd be nice if he either: * Moved the chat overlay to the bottom-left (covering the same paragraph as his head) or * Squeezed the window for the article text so that it no longer overlapped underneath the chat and head feeds I don't always read along but when I do (e.g., when there's code), there's only a narrow sliver of unobstructed vertical space. Many paragraphs get scrolled through it too quickly to even reliably pause at the right moment.

There is a reason people rewrite it in rust more often than write it in rust. its easier to iterate in simpler languages (GO) and convert to rust when you know at least 75% of the features . and u get capital to hire 200k/yr rust devs if u finish the product first.

of course you think colors suck when the language doesn't allow you to type them (Algebraic Effects), mix them (Fused Effects), and create new ones (Monads) :)

why not just poll futures manually?