rabidferret

Every single one of those bullet points is a primary design goal of Diesel (caveat: Our semantics generally map to PG, because they apply well to other backends and are the least nonsensical)

It wasn't super clear, anyway. Fixed in https://github.com/sgrif/diesel.rs-website/pull/5 :)

FWIW making sure it's easy to add extensions like this is part of the core design of Diesel. For example, this adds full text search support (it's slightly out of date) https://github.com/sgrif/diesel_full_text_search/blob/master...

If you're interested in adding postgis support, ping me in our Gitter room. I'd be happy to help.

I'm having Jose on The Bikeshed (bikeshed.fm) next month to compare notes!

I think it's green, at least in the US. XD

> The types should be able to ensure you don't have any errors even with so many "redundant" types

Correct. Sorry, I should have been clearer in my last comment. The reason you'd want a separate type for insert is because wrapping your id in an `Option` would be painful for anything except insert.

> but my first thought is of how much boiler plate will result.

Yeah, if you're coming from Active Record (which is the other project I maintain), we'll probably seem a little bit verbose. My goal here is to be 80% as nice to get started with, but nudge users towards significantly more maintainable code as their product grows.

> I would guess most record types will be very similar between create, update, and retrieve.

Early on, yes. 2 years in, not so much.

> Also, what about upsert?

This is something I'd like to add support for in the future. This comment made me realize I didn't have a tracking issue, so here it is: https://github.com/sgrif/diesel/issues/196

Rails 2 scopes are literally the case for composeability...

This can be accomplished without procedural macros, too. ;)

Short version: Because Rust's type system is a joy to use, and the reason I made Diesel was to try and push it forward in higher level contexts. I'm finding myself more productive in Rust than I am in any other language.

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

Update yes. It's possible to use the same struct for create, too if you really want, but you'd need to wrap `id` in an `Option`.

Generally we're designed for the idea that you'll have a separate struct for read, create, and update. We also try and design for the latter two mapping roughly to web forms, as this is how most large applications end up wanting to be structured from my experience.

The main thing I'm trying to avoid is lumping all your logic in a single place, and ending up in many of the same rabbit holes that Active Record has led us to (which is at least partially my fault)

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

Oh I know, I didn't think you were. Just stating a random thought I've had about the examples on the site. XD

I think we're violently agreeing in a lot of ways. :)

I'm curious what you mean by scale. Are you referring to performance, or code size? If you're referring to performance, you'll probably find it interesting that we out-perform or are competitive with ideomatic C.

Yeah, I'm planning on killing Arel at some point. I actually want to extract `Relation` to a gem entirely, as it's really not an adequate query builder for what we need in AR.

Also random fun story about Arel not being immutable. We had a bug in 4.1 where basically PG bind params are ordered, but Relation can't actually know the order ahead of time (e.g. because a Relation can be used in a from clause). Turned out actually fixing it was somewhat hard (the "real" fix was eventually https://github.com/rails/arel/commit/590c784a30b13153667f8db...). But as a hack, basically someone took advantage of the fact that `Arel::Nodes::BindParam < SqlLiteral` and `SqlLiteral < String`, and Strings are mutable. So they just ignored the lack of a proper map function, and fiddled with the strings. >_>

Anyway, yeah our AST is fun because Rust's compiler lets us set it up so that we can walk it as many times as we need basically for free (because it gets monomorphised and the walking ultimately gets inlined and optimized away)

Stored procedures are no more composeable than SQL strings are. Now it's certainly easy to say that I haven't used SQL directly. But I did spend years working that way (though of course this statement shouldn't give you much confidence by itself).

Ultimately an ORM can help you to build more maintainable and resilient (to changing market conditions) software than direct SQL. Diesel in particular can catch mistakes that SQL strings cannot.

I do understand why a lot of people have reservations about ORMs. I share a lot of them. I've maintained Active Record for about 2 years now, and learned a lot from doing so (note: This does not mean that I like AR or want this to be anything like it).

TL;DR: Your points aren't wrong. Diesel is different. Maybe give it a shot. ;)

You should take a closer look at what Diesel is doing with it's query builder. We actually do attempt to support the full power of every supported backend (of course there's still holes which need to be filled), with proper type guarantees which map to the semantics of Postgres. The main difference being that Diesel can check your queries for correctness at compile time.

The CLI just generates the file structure. We fill in the SQL manually as part of the guide, and then create the structs immediately after that.

Thanks. The designer is taking another pass at it soon, I didn't expect to have so much traffic. I'll bump up the color on the links until then.

Yeah, I've been wondering if I should note somewhere in the examples that we don't actually execute `SELECT *`, we do something more reliable. I felt like listing every column would bury the lede though.

It's technically for the Republic of Serbia. I only chose it because .io was taken by a python library (which I wish I'd checked before deciding on the name)

It's also a pain in the ass to register because you have to have a Serbian tax ID

In that very specific example, you are right -- the benefits are pretty minimal (mostly just the deserialization). However, you're actually able to represent the relationship between those two models however you want, but still deal with relationships between types, and not what the exact join clause is.

Additionally, SQL is extremely hard to compose. In my applications, I very rarely have some specific one off query that I want to run, I have multiple predicates that I want to be able to mix and match easily. String munging is fragile, while this actually lets me build reasonable domain abstractions.

To your final point "Unless this has some huge performance gain over rust-postgres"

Diesel performs 33% faster than rust-postgres, and will be competitive with if not faster than ideomatic C.

Mind posting a screenshot of what you're seeing? All our code samples are `font-family: monospace`

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()`.

> You put the whole thing on Github, yet, you ask for a monthly fee?

Yes, we've been doing this a lot lately. Nothing to stop you from running your own server, we're charging for our deployment.

> So, this is basically like gitter, but for any site?

Medium-style comments.

It's also used for the comments at robots.thoughtbot.com