Because ORM attribute access usually trigger requests, and you must design the API so that those requests, which trigger called to the network, don't block.

I see, the ORM backed objects are lazy and trigger I/O when the data is accessed. On first blush I'm surprised that Rust culture would go for this as it spread network i/o (incl network errors), async waiting and memory allocation widely in your code. This would seemto hamper eg the common "functional core, imperative shell" architecture which gets you many of the classic FP virtues. I wonder if I'm missing something that makes these less of a problem?

this has been a solved problem for... a long time, can't remember how long even.

https://docs.sqlalchemy.org/en/20/orm/queryguide/relationshi...

the older I get the more I'm convinced this should be the default behavior.

I think you are talking past each others. Preventing N+1 by doing lazy fetching and having synchronous / asynchronous API are orthogonal issues. Async API must not block the thread/event loop when the data loading is being done.

Diesel hasn't been providing an async API for reason told in this thread: https://github.com/diesel-rs/diesel/issues/399

The situation might change some day though, once async support in the core language and surrounding ecosystem gets stronger.

diesel_async exists and is also maintained by the same creator.

Yes, but it started as a experiment, and isn't official part of Diesel yet.

The creator said it is production ready, and that it will never be "officially" part of diesel as diesel only supports a sync interface. Nevertheless, diesel_async is fully fine to use, he mentions.