zlacker

[return to "The bane of my existence: Supporting both async and sync code in Rust"]
1. andrew+hc[view] [source] 2024-01-19 23:05:58
>>lukast+(OP)
I don’t know how different it is from Rust, but in javascript supporting async and sync is smooth as a Swiss watch.

In Python it takes more thinking and structure because async isn’t built in deeply like it is with javascript.

Even so, async versus sync doesn’t feel like a nightmare in either.

Having said that, it depends entirely on how much experience you have with async programming.

Async programming is a mind bender that will throw you completely until it becomes natural. Synchronous programming feels natural and logical and async requires a completely different mental model.

I can understand why anyone forced to do async would hate it. It’s something you have to want to do.

◧◩
2. sgbeal+Xi[view] [source] 2024-01-19 23:46:33
>>andrew+hc
> in javascript supporting async and sync is smooth as a Swiss watch.

Ha! Integrating async I/O sources, namely the OPFS API, has been the single biggest development-time hit and runtime performance hit in sqlite.org's JS/WASM build of sqlite.

As soon as a single method is async, it cannot be hidden behind a synchronous interface because the async attribute is "viral," requiring the whole API above it to be async (which sqlite is not). We instead have to move all of the async I/O into its own worker and "fake" synchronous access to it using a complex proxy built from SharedArrayBuffer and the Atomics API. It's an abomination but it's the only(?) approach for making async functions behave fully synchronously which doesn't require third-party voodoo like Asyncify.

PS: the opposite - hiding sync stuff behind an async interface - is trivial. Hiding async behind a synchronous interface, however, is a tremendous pain in the bottom in JS.

[go to top]