3 ms·

+1 It seems like the intersection of good use case for Rust and need to use SQL, will also intersect with "minimal SQL needs", hence preference for simpler lib

+1 It seems like the intersection of good use case for Rust and need to use SQL, will also intersect with "minimal SQL needs", hence preference for simpler libraries.

deleted 11y ago
[deleted]
- brandonbloom 11y ago
  Mentioned below where? If you're talking about query string construction performance, I'm not sure I've ever seen even a Ruby application where query string building was a bottleneck vs the network.
  - steveklabnik 11y ago
    Sorry, as you replied I had deleted my comment, because I decided I'd rather not get into an argument about this :) I will give you the link though: https://news.ycombinator.com/item?id=11045700 https://news.ycombinator.com/item?id=11045700 <- "Diesel performs 33% faster than rust-postgres, and will be competitive with if not faster than ideomatic C. "
    - brandonbloom 11y ago
      Forgive me, I didn't intend to be so argumentative. I genuinely want to understand. I'm trying to figure out if there are whole categories of use cases that I just don't have any exposure to. As a side note: I keep trying Rust over and over again, and just can't get in to it. I think my brain just doesn't work that way. For my hobby project that needs super low level perf, I've moved a codebase from C, to Rust, and now to http://terralang.org/ http://terralang.org/ and I'm finally quite satisfied with how the project is going.
      - rabidferret 11y ago
        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.
      - steveklabnik 11y ago
        Naw, it was my response that was more so than I wanted it to be. No worries. :) Rust focuses on "zero-cost abstractions", that is, if you had to implement a feature yourself, you couldn't do it any better. So this library, while more complex than a straightforward binding, has more features that are useful, like increased safety, while also being faster. A win-win. And very much in line with Rust's overall philosophy.

+1 It seems like the intersection of good use case for Rust and need to use SQL, will also intersect with "minimal SQL needs", hence preference for simpler libraries.

deleted 11y ago

[deleted]

brandonbloom 11y ago
Mentioned below where? If you're talking about query string construction performance, I'm not sure I've ever seen even a Ruby application where query string building was a bottleneck vs the network.
- steveklabnik 11y ago
  Sorry, as you replied I had deleted my comment, because I decided I'd rather not get into an argument about this :) I will give you the link though: https://news.ycombinator.com/item?id=11045700 https://news.ycombinator.com/item?id=11045700 <- "Diesel performs 33% faster than rust-postgres, and will be competitive with if not faster than ideomatic C. "
  - brandonbloom 11y ago
    Forgive me, I didn't intend to be so argumentative. I genuinely want to understand. I'm trying to figure out if there are whole categories of use cases that I just don't have any exposure to. As a side note: I keep trying Rust over and over again, and just can't get in to it. I think my brain just doesn't work that way. For my hobby project that needs super low level perf, I've moved a codebase from C, to Rust, and now to http://terralang.org/ http://terralang.org/ and I'm finally quite satisfied with how the project is going.
    - rabidferret 11y ago
      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.
    - steveklabnik 11y ago
      Naw, it was my response that was more so than I wanted it to be. No worries. :) Rust focuses on "zero-cost abstractions", that is, if you had to implement a feature yourself, you couldn't do it any better. So this library, while more complex than a straightforward binding, has more features that are useful, like increased safety, while also being faster. A win-win. And very much in line with Rust's overall philosophy.