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.
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.
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
xzvulnerability 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.