rabidferret

Can you elaborate on how Diesel doesn't compose in this way? Composition is one of the main goals of Diesel.

If you open an issue we can up the limit again

I think people read way too much into the ORM label. Diesel is very much a query builder first, not an ORM. As a random data point, I've been fixing bugs in Rails lately by basically copying over code from Diesel and converting it to Ruby. That code has all been in Arel not Active Record.

I agree that the "I make Rails" thing is a double edged sword. I would hope people would see it as an indicator that I have a lot of experience and lessons to learn from, but I think many people see the opposite.

We didn't want to commit to our own home-grown hlist type until we had some indicator of whether the language was going to go with variadics based on tuples or hlists.

It'll eventually go away when some form of variadic generics lands in the language

Ironically, I was actually originally planning on having Diesel primarily built around parsing actual SQL. (See the commit message of https://github.com/diesel-rs/diesel/commit/2ba8bf481c3d21d8b..., which is like commit number 4)

I agree that if you're just writing a single self-contained query, SQL is a great DSL for that. I've been trying to improve our story for working with raw SQL (one tradeoff will be that it isn't type checked).

However, there are major benefits to an in-language DSL as well. If you are wanting to re-use fragments of queries, or conditionally construct a different query, that's a pain to do with SQL strings.

Slick was definitely an influence on Diesel's design. I tried to have our query builder map more closely to SQL though, whereas Slick feels like it's trying to pretend it's just an Iterable.

You could just as easily write `posts.filter(user_id.eq(1)).load(&connection)`.

Not a HashMap specifically, but there is a way to group them into `Vec<(User, Vec<(Post, Vec<Comment>)>)>`. (Which you can convert into a hashmap pretty easily) http://docs.diesel.rs/diesel/associations/index.html for details.

Uh... Custom derive?

"requires unsafe" already implies everything in your comment. `unsafe` literally means "this might violate memory safety"

That doesn't mean that a 500 is a good UX. We give error messages on invalid form input for a reason.

Yeah, ultimately it's fundamentally no different than Go but with more sugar and ability to abstract properly. Turns out that counts for a lot.

I think that's only the case when you are specifically trying to avoid boxing.

Just because a type can be named doesn't mean that returning the named type properly expresses your intent.

The name of said type can get real hairy real fast, as well.

> it's almost never required

Mate you should try Diesel or Futures. ;)

Most in depth I went was probably in http://m.youtube.com/watch?v=PUuYAksQWg4 but I discuss it in pretty much every talk I give.

You can also just ping me on Twitter and I can talk about it more. :)

I talk about this at length in one of my recent talks but the short version is we wanted to optimize for reuse via named scopes

For an insurance policy like that, they wouldn't offer any policy without auditing the device, including the code.

This isn't true at all. You can add as many fields as you want. You'll need to recompile to use them, of course.

That is our `sql` function

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`

Hah I love this answer. ^_^

We have a SQL literal ast node but you lose most of the benefits of the library that way

> 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.

It's a bit late here, but feel free to DM me in our Gitter room and I can give you a full explanation tomorrow.

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!)

Diesel's selling point isn't actually the performance aspect. It's the safety and productivity.

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'll take your word for it. I'm no gas can expert. :)