In the context of my original post: 1) garbage collection, which isn't a big deal for most server applications and 2) simplicity, where the complexity of Rust only buys me marginal performance of questionable utility for the sorts of use cases where I'd be talking to a SQL database.

But the sorts of use cases where you'd be talking to a SQL database do benefit from generics and ADTs. For example, generics are good to avoid having to write for loops over and over, which is pretty pointless for application code (and, I'd argue, for systems code as well--for loops are just bad). Pattern matching is nice for high-level app logic, which often has the flavor of "if A, do X; if B, do Y; else do Z". Generics enable try!, which is a lot nicer than C-style error handling. And so on.

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

We're not going to settle the dynamic vs static debate in this thread, so I'll refrain from commenting on safety and productivity :-)

Anyway, I don't mean to dump on your work. It seems like it's actually quite a nice implementation. I'm just questioning 1) the size of the audience and 2) Whether or not the audience who thinks they want this should actually want this.

If the size of your audience is your overriding concern, you shouldn't be writing your ORM in Go or Rust.