5 ms·

How come?

Scarbutt 9y ago
Maybe because of the language constructs that facilitate functional programming, you would think a data driven centric approach would be chose first over objects.
- steveklabnik 9y ago
  Rust doens't have objects. (Trait objects kind of come close but are very rare and I've never used one with Diesel.) I think if you read the post, you'll see that Diesel is very data-driven. Personally, I tend to call it a "query builder" if I think someone might be ORM-phobic; I find it closer to that than other ORMs, even though it's authored by the maintainer of one of the most massively popular ORMs ever. They've sometimes joked that that experience has taught them what not to do ;)
  - Scarbutt 9y ago
    Thanks for clarifying. A subjective note, the executed SQL is way more beautiful than the Rust code ;) and to me, defines the intention better, a nicer approach to me would be if the syntax/grammar would have been more SQLish.
    - leshow 9y ago
      One benefit of the diesel approach is that it's type safe, whereas the pure SQL approach isn't.
      - u320 9y ago
        There is no technical reason why you couldn't create a fully typesafe pure SQL interface in Rust, the same way Rust's format language is typesafe.
        steveklabnik 9y ago
        This is true, but to do that, you need procedural macros, which are not yet stable.
    - rabidferret 9y ago
      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/2ba8bf481c3d21d8b6b731bd9ae6c290f70b57e7 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.
      - crzwdjk 9y ago
        You don't need to work with SQL strings though, you can work with ASTs or other higher level abstractions, and with Rust's macros and the infer_schema! machinery you can probably find a way to project the SQL types into Rust's type systems to keep things more or less type-safe. But then again, I've never tried to write such a thing, so maybe it's not quite as easy as that. I've definitely used a similar query-builder library in the past though and while it definitely had its benefits over raw SQL, it also led to some abuses where bits and pieces were used to compose gargantuan queries that nobody would have ever thought to write by hand.
  - gchp 9y ago
    > even though it's authored by the maintainer of one of the most massively popular ORMs ever Just curious, what ORM is that?
    - steveklabnik 9y ago
      ActiveRecord. Referencing it is a double-edged sword; Diesel is very much not ActiveRecord, so by saying it up front, people tend to get the wrong impression.
      - gchp 9y ago
        IThat's cool, didn't realise it was the same author. I understand. The other side of that coin though I guess is that knowing this might give some more confidence in using diesel. ActiveRecord was the first ORM I used, and knowing now that diesel is "from the same stock" (for want of a better phrase) gives some extra confidence in what it can do / where it is going. Not that I was not confident in it before...
        steveklabnik 9y ago
        Yup, absolutely, that's the other side of the sword :)
        dmix 9y ago
        Indeed, the flood of Rails people who went over to Rust have definitely given some people pause to consider the direction it was taking. I don't see this particular case of someone who spent a significant amount of time coding core Rails OSS library being seen as a negative though, quite the opposite. If anything it would be an excellent measure of the language for that particular use case assuming any competent developer would seek to operate in the constraints of the language rather than shoehorning an existing implementation into something that doesn't fit. The bigger question is whether the ORM label itself is limiting or can be understood to fit into a broader scope of implementations.
  - u320 9y ago
    > it's authored by the maintainer of one of the most massively popular ORMs ever Cool, didn't know Sean Griffin maintained Hibernate!
    - steveklabnik 9y ago
      I'm not sure what you're saying, I put a "one of" in there for a reason. I'm not particularly interested in debating which ORM is the most popular, but it's undeniable that ActiveRecord is in the set of ones you'd be considering if you were trying to answer that question.
  - jsd1982 9y ago
    Given the previous experience of authoring a popular ORM, why repeat the mistake of pluralization of table names from model names? I've always found this convention to be problematic at best and I've learned to avoid it. Maintaining consistency of names inside and outside of code makes searches and references easier to follow without having to mentally (or even mechanically) expand the singular name to plural name or vice versa (say, in a scratch pad to compose a test query).
    - steveklabnik 9y ago
      I guess not everyone considers that a mistake, but at least it's very easy to change; tack on a #[table_name="whatever"] and you're done. I'm not sure if there's a more global way, since I don't mind pluralization.
      - jsd1982 9y ago
        Yeah, it's just my opinion tempered with experience. Is the pluralization rule literally as simple as stated in the article, namely appending an 's' and calling it done? English is rarely so simple and there are tons of corner cases which is why I tend to frown on the pluralization rules that are unpredictable. Those must be a nightmare for English-as-a-second-language folks too.
        steveklabnik 9y ago
        Oh yeah, I remember thanks to ActiveSupport::Inflector, heh. Yes: https://github.com/diesel-rs/diesel/blob/e52d1710d98a05c3aa4663017ec47dbb40e1d747/diesel_codegen/src/model.rs#L72-L76 https://github.com/diesel-rs/diesel/blob/e52d1710d98a05c3aa4... But it also converts CamelCase to snake_case: https://github.com/diesel-rs/diesel/blob/e52d1710d98a05c3aa4663017ec47dbb40e1d747/diesel_codegen/src/model.rs#L56-L70 https://github.com/diesel-rs/diesel/blob/e52d1710d98a05c3aa4...

How come?

Maybe because of the language constructs that facilitate functional programming, you would think a data driven centric approach would be chose first over objects.

steveklabnik 9y ago
Rust doens't have objects. (Trait objects kind of come close but are very rare and I've never used one with Diesel.) I think if you read the post, you'll see that Diesel is very data-driven. Personally, I tend to call it a "query builder" if I think someone might be ORM-phobic; I find it closer to that than other ORMs, even though it's authored by the maintainer of one of the most massively popular ORMs ever. They've sometimes joked that that experience has taught them what not to do ;)
- Scarbutt 9y ago
  Thanks for clarifying. A subjective note, the executed SQL is way more beautiful than the Rust code ;) and to me, defines the intention better, a nicer approach to me would be if the syntax/grammar would have been more SQLish.
  - leshow 9y ago
    One benefit of the diesel approach is that it's type safe, whereas the pure SQL approach isn't.
    - u320 9y ago
      There is no technical reason why you couldn't create a fully typesafe pure SQL interface in Rust, the same way Rust's format language is typesafe.
      - steveklabnik 9y ago
        This is true, but to do that, you need procedural macros, which are not yet stable.
  - rabidferret 9y ago
    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/2ba8bf481c3d21d8b6b731bd9ae6c290f70b57e7 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.
    - crzwdjk 9y ago
      You don't need to work with SQL strings though, you can work with ASTs or other higher level abstractions, and with Rust's macros and the infer_schema! machinery you can probably find a way to project the SQL types into Rust's type systems to keep things more or less type-safe. But then again, I've never tried to write such a thing, so maybe it's not quite as easy as that. I've definitely used a similar query-builder library in the past though and while it definitely had its benefits over raw SQL, it also led to some abuses where bits and pieces were used to compose gargantuan queries that nobody would have ever thought to write by hand.
- gchp 9y ago
  > even though it's authored by the maintainer of one of the most massively popular ORMs ever Just curious, what ORM is that?
  - steveklabnik 9y ago
    ActiveRecord. Referencing it is a double-edged sword; Diesel is very much not ActiveRecord, so by saying it up front, people tend to get the wrong impression.
    - gchp 9y ago
      IThat's cool, didn't realise it was the same author. I understand. The other side of that coin though I guess is that knowing this might give some more confidence in using diesel. ActiveRecord was the first ORM I used, and knowing now that diesel is "from the same stock" (for want of a better phrase) gives some extra confidence in what it can do / where it is going. Not that I was not confident in it before...
      - steveklabnik 9y ago
        Yup, absolutely, that's the other side of the sword :)
        dmix 9y ago
        Indeed, the flood of Rails people who went over to Rust have definitely given some people pause to consider the direction it was taking. I don't see this particular case of someone who spent a significant amount of time coding core Rails OSS library being seen as a negative though, quite the opposite. If anything it would be an excellent measure of the language for that particular use case assuming any competent developer would seek to operate in the constraints of the language rather than shoehorning an existing implementation into something that doesn't fit. The bigger question is whether the ORM label itself is limiting or can be understood to fit into a broader scope of implementations.
- u320 9y ago
  > it's authored by the maintainer of one of the most massively popular ORMs ever Cool, didn't know Sean Griffin maintained Hibernate!
  - steveklabnik 9y ago
    I'm not sure what you're saying, I put a "one of" in there for a reason. I'm not particularly interested in debating which ORM is the most popular, but it's undeniable that ActiveRecord is in the set of ones you'd be considering if you were trying to answer that question.
- jsd1982 9y ago
  Given the previous experience of authoring a popular ORM, why repeat the mistake of pluralization of table names from model names? I've always found this convention to be problematic at best and I've learned to avoid it. Maintaining consistency of names inside and outside of code makes searches and references easier to follow without having to mentally (or even mechanically) expand the singular name to plural name or vice versa (say, in a scratch pad to compose a test query).
  - steveklabnik 9y ago
    I guess not everyone considers that a mistake, but at least it's very easy to change; tack on a #[table_name="whatever"] and you're done. I'm not sure if there's a more global way, since I don't mind pluralization.
    - jsd1982 9y ago
      Yeah, it's just my opinion tempered with experience. Is the pluralization rule literally as simple as stated in the article, namely appending an 's' and calling it done? English is rarely so simple and there are tons of corner cases which is why I tend to frown on the pluralization rules that are unpredictable. Those must be a nightmare for English-as-a-second-language folks too.
      - steveklabnik 9y ago
        Oh yeah, I remember thanks to ActiveSupport::Inflector, heh. Yes: https://github.com/diesel-rs/diesel/blob/e52d1710d98a05c3aa4663017ec47dbb40e1d747/diesel_codegen/src/model.rs#L72-L76 https://github.com/diesel-rs/diesel/blob/e52d1710d98a05c3aa4... But it also converts CamelCase to snake_case: https://github.com/diesel-rs/diesel/blob/e52d1710d98a05c3aa4663017ec47dbb40e1d747/diesel_codegen/src/model.rs#L56-L70 https://github.com/diesel-rs/diesel/blob/e52d1710d98a05c3aa4...