30
Announcing Diesel 2.3.0 (diesel.rs)
submitted 1 year ago by to c/rust@programming.dev
10 comments fedilink hide all child comments
 

I'm happy to announce the release of Diesel 2.3. This release contains various extensions to the query DSL provided by Diesel and enables using Diesel in web browsers via the wasm32-unknown-unknown target.

Checkout the full release announcements for more details.

As always you can support my work on Diesel by contributing or sponsoring the project.

I would like to use this possibility to thank NLNet Foundation for funding the newly added window function extension.

I'm happy to answer any question that comes up.

you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 1 year ago (4 children)

Awesome! I honestly didn't recognize that the username here and from the repo were the same.

Honestly, the fact that you maintain diesel and diesel-async gives it a ton of credibility. I'll have to play with it! I was mostly worried this was a shim made by some rando in the community and it could break at any time, but if the core maintainer is also associated with the parent project, that's less likely.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] [S] 3 points 1 year ago (3 children)

    While I can understand your concern, I‘m technically speaking also just some rando in the internet. It’s likely a better solution to evaluate crates a somewhat independently from their authors and and bit more on the actual code, quality and number of other projects dependent on such a crate. Sometimes such crates from someone in the community are real gems.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 1 year ago (2 children)

    Agreed. My point was that you'd probably know more about the relationship between the projects than some rando. I've seen plenty of misinformation from people making claims about projects that don't hold.

    And yeah, I've found great crates from smaller projects. That said, I'm always worried about an xz issue where a small, impactful project gets targeted by malware authors and their changes get in because there's not enough people involved in the project. Or maybe it's as simple as the lone maintainer stopping work on the project and the project stagnates. If it's not something I'm willing to step in and maintain or replace myself, I'm going to go with a larger project, even if it's not quite what I'm looking for, and DB libraries definitely fall into that category.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] [S] 1 point 1 year ago (1 child)

    These are certainly valid considerations, but I would like to point out that just because a project seems large on the outside that does not guarantee that it has enough maintainers. Most open source projects are still run by a single person. That is still mostly the case for diesel, but also applies to much larger projects like curl. So while it might feel like a „large“ project will protect you from such issues, that’s really no sufficient guarantee. The only way you could make sure to not run into such problems is by auditing all of your dependencies.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 1 point 1 year ago

    Oh absolutely. In fact, I created a package that currently has millions of weekly downloads that I don't really maintain anymore (someone else volunteered). So I'm pretty familiar with these issues. People burn out or move on or whatever.

    The reason I like larger projects is because it's more likely someone will notice if there's a problem. There's no guarantee, sure, but more eyeballs is generally a good thing, and that's how the xz vulnerability was caught so quickly. It's better if a project has a healthy amount of contributors, but all things being equal, I prefer a popular project to a less popular one. How many people would notice an issue in diesel-async vs diesel? How many are like me and would use the async features if it's in the main project, but would hesitate if it's a separate crate?

    None of this has anything to do with the quality of of the code or maintainers, it's purely about the number of eyeballs.

  • permalink
  • fedilink
  • source
  • parent