If you just want to build a normal backend service, you can't escape async libraries. Wrapping the async functions with `block_on` is not ideal I'd rather just have access to standard sync primitives that don't need me to bring an entire async runtime into the system.

My ultimate point is - I would be happy if async stayed in its own world. But the fact is async has completely polluted the rust library landscape and you can't escape it. I'm working on a project that I hope to show rust users that async isn't needed for performant backend services, and that the code can be written much simpler without it.

The UMCG implementation allows kernel thread context switches to happen in 150-200 microseconds, compared to the 1500-2000 microseconds for normal kernel thread context switches. My goal is to show that if UMCG could be merged into the Linux run time then then it would be competitive with async rust without the headache.

I wish to God that the rust library devs would admit to this fact - say that async rust should stay for embedded runtimes usecases, but we shouldn’t be forcing async across the majority of general purpose computing libraries. It’s just not a pleasant experience to write nor read. And it really doesn’t give any performance benefits.

I'm pretty close to being done - I'm hoping to publish the entire GitHub repository with tests for the community to validate by next week.

UMCG is essentially an open source version of Google Fibers, which is their internal extension to the linux core for "light weight" threads. It requires you to build a user space scheduler, but that allows you to create different types of schedulers. I can not remember which scheduler showed ^ results but I have at least 6 different UMCG schedulers I was testing.

So essentially you get the benefits of something like tokio where you can have different types of schedulers optimized for different use cases, but the power of kernel threads which means easy cancellation, easy programming (at least in rust). It's still a linux thread with an entire 8mb(?) stack size, but from my testing it's far faster than what Tokio can provide, without the headache of async/await programming.

I'll publish my results shortly. I did these as baselines because I'm testing finishing the User Managed Concurrency Groups proposal to the linux kernel which is an extension to provide faster kernel threads (which beat both of them)

fwiw - My favorite language is Rust, but Async Rust has ruined it for me.

For your own application code, you don't have to use exceptions you can write custom Result objects and force callers to pattern match on the types (and you can always wrap library/std exceptions in that result type).

Structured Concurrency looks like a banger of a feature - it's what CompletableFuture should've been.

VirtualThreads still needs a few more years for most production cases imo, but once it's there, I truly don't see a point to choose Go over Java for backend web services.

Now, I still recommend reading that proposed legislation because it sets the context up for these other links.

* Loose Threads PDF https://www.docdroid.net/3sZ9MaI/loose-threads-pdf (very, very long read) * Ratcliffe July 2023 https://twitter.com/highpeaks77/status/1685669297308282881 * Ratcliffe January 2023 https://twitter.com/UAPJames/status/1614644671589892101 * Ratcliffe June 2021 https://www.youtube.com/watch?v=pPDeuy_YSs0 * HOC Hearing July 26, 2023 https://www.youtube.com/live/SNgoul4vyDM?si=oBkDt3j63uDL63Tr * HOC Hearing Nov 13, 2024 https://www.c-span.org/video/?539937-1/hearing-unidentified-...