Short version: Our compile time guarantees allow us to omit a lot of runtime checks that you would otherwise have.

Long version: http://bikeshed.fm/49

Longer version: Planning on doing a really in depth write up for the website soon. I'll also be going into more detail during my talk at the SF rust meetup, which there's a link to the live stream towards the bottom of the thread

I'm interested if some of those guarantees can be used upstream in rust-postgres?

As far as I saw, Diesel is essentially shipping with its own PostgreSQL driver.

It's possible. I tried to build on rust-postgres originally, but its design basically makes it impossible to abstract over. We also have fundamentally different views on how `ToSql` should work.

I'd love to find out what made it impossible to abstract over?

Please include in your larger talk!

The short version is its refusal to box things means that you have to have the connection, the statement, and the cursor all as local variables in the same lexical scope (you almost always want to abstract away the statement and cursor), and it's use of trait objects for serialization and deserialization. I might go into it briefly in my talk, but I don't like to rag on other people's work so I probably won't say much on it.

(Sorry for the double post, I think I replied to my own comment and not yours!)

And rusqlite (or libsqlite-3) doesn't have those issues?

I don't think you're ragging on rust-postgress, although I'd probably attempt to change rust-postgres first :P

> And rusqlite (or libsqlite-3) doesn't have those issues?

rusqlite has the same issues. libsqlite doesn't since it's just C bindings. Same as pq_sys. Ironically, rusqlite makes the same design choices as rust-postgres, but it's actually wrapping a heap allocated object anyway, so it gains nothing by doing so...

> I'd probably attempt to change rust-postgres first

I did, too. It turned out to be a pretty major rewrite.