This is still one of Rust's major shortcomings. Async IO, particularly async database and network IO, are still pretty much nonexistent in any practical sense. Some libraries are in the works, but for the time being, I'm still passing over Rust for any real work.

It's very close to landing in hyper, which should then percolate up through the rest of the ecosystem, at least, HTTP-wise.

Do you know of any resource that would explain the current status of running rust as a webservice server endpoint ?

I'm thinking of question such as :

-embedded http server vs using apache or nginx ( eg : node and go seem to favor not using third party servers at least for simple cases)

- prefered concurrency model ? ( async vs thread based vs coroutines vs...)

- deployment issues ? ( single binary with everything inside, vs parts that need to be predeployed on the server beforehand)

- third-party connectivity ? ( diesel seems like a really fantastic way to query a db, but what about other storage such as s3, mongo, redis, queue systems, etc)

- current frameworks status ?

I know it sounds like a lot, but as ORMs is usually the major pain point for me when looking at a new techno ( it's one of the main reason i'm not using go, for example) and now that diesel seems to answer all my needs, i'm REALLY looking forward to start using Rust. I just need those questions to be answered, and i think i'm not the only one.

I don't know of one, so let me write up something short:

  > embedded http server vs using apache or nginx 

For now, put nginx in front of things, at least if you're using one of the non-rotor frameworks. That's because they are synchronous for now. This will change soonish, more below.

  > prefered concurrency model ?

If you're using a framework, this is handled for you already. If you're building something custom, you probably want to use something like mio to make it asynchronous. Current frameworks are all using synchronous IO, but work is undergoing to switch that, which will then percolate upwards through the ecosystem.

  > deployment issues ?

By default, everything is statically linked except glibc, so you make sure that those are compatible and then copy the binary.

  > third-party connectivity ?

Wonderful or nonexistent depending. We're still youngish, so there's gaps. Support ranges from "provided by the vendor itself" (mongo) to "nonexistent" (some random noSQL store that might be popular amongst a certain group but someone hasn't written a binding yet)

  > current frameworks status ?

The two most well-known are Iron and Nickel. Crates.io uses its own homegrown framework due to age. The author of Diesel may or may not be working on a new one to go with it...

> The author of Diesel may or may not be working on a new one to go with it...

IIRC, he hints at working on one (I think with Yehuda Katz?) in the podcast where he talked about Diesel:

http://bikeshed.fm/49

I'm not sure I entirely understand the question, but we ultimately end up hooking into libpq, and right now the queries are synchronous. As we look towards features like associations, this will actually have to be true to some extent, since if we want the return type to be `(User, Vec<Post>)`, we actually need to allocate the entire result set we're reading into memory to implement `next()`.

Would it be desirable or possible to instead return a lazy collection that only fetches perhaps 10 results and fetches more as you iterate?

It's impossible. We can't guarantee the order of the result set, so we'd have to iterate the entire collection just to implement `next`