This is an automated archive made by the Lemmit Bot.

The original was posted on /r/rust by /u/Sib3rian on 2024-04-08 08:17:16.

Let’s say I’m working on a hobby web app, so I keep things simple and go with SQLite; more specifically, the wonderful rusqlite crate. The app released and works well, so it takes off, but as my user base grows, I realize I could benefit by switching to a client-server database.

However, rusqlite is synchronous. Even if I abstracted database access with something like the repository pattern, I’ve committed to synchronous Rust. Moving to, say, Postgres means I’ve got to mark every function that calls into the database async and adjust the functions that call those—my domain layer—accordingly. It’s a leaky abstraction. The domain layer should not care in what manner the data is retrieved.

Furthermore, if I initially went with a synchronous web server, I would need to rewrite my entire web layer. Ideally, web frameworks would let us describe the what of our app—the routes, the extractors, the middleware—and be generic over the how.

Is that possible? I realize there’s a lot of complexity hiding inside asynchronous Rust, but I don’t understand it well enough to say if it’s accidental or essential in respect to the higher-level apps that use it.

If it’s not doable today, could it be in the future? Asynchronous Rust is, after all, only half-complete. Have other languages—perhaps in the functional family—solved this problem, and could Rust learn from them?