metrics VS rust-foundation-community-grant

It's worth keeping an eye on Diesel's metrics suite (https://github.com/diesel-rs/metrics) as well; I found and fixed some suboptimal buffering that was affecting performance.

See here for some numbers. The relevant code lives inside the diesel github repository. Please also keep in mind that these are just numbers and you should run those these on your own and also run tests with your actual work load.

Performance is worse than in comparable frameworks

No it will likely not be less performant. See these numbers for some benchmark results for numbers. (As always with benchmarks: Please don't trust my numbers. To be sure you need to do your own benchmarks with your own use-case)

See here for some benchmark results. The benchmarks itself are in the diesel repository. Otherwise I believe there are numbers in the techempower benchmarks as well, although that includes other factors .

I'm developing a Rust web server backend in Axum that uses Postgres and performance will be pretty important since I plan to run it on one server for as long as possible. It seems like the postgres crate is about 2x faster than sqlx, and the postgres repository seems pretty active still.

Congratulations to the release. I know all of this is hard work. I would like to invite you to submit a ormlite implementation to the diesel benchmark collection. As soon as that's merged you will get regular reports here. The relevant code is here in the diesel repository.

In that case you may be interested in the metrics for different database libraries. diesel is doing rather well at the moment. sqlx is in the middle of a large rewrite that should improve performance, so we'll see how it compares after that

See here for some benchmark results for the diesel repository. Please keep in mind that as always with benchmarks, these numbers are not necessarily true for your usecase. Be sure to checkout at least the benchmark code and draw your own conclusions from there.

The cited 7-70x factor is for sqlite, it's not that serve for other backends. I would guess for sqlite the overhead is partially caused by forcing an async interface on top of a internally sync API. See here for some numbers.

That's a topic where already some work exists. You might want to checkout my collection of bad error messages from such trait heavy crates for example. It's important to notice that most of these errors look complicated, but mostly have a quite simple cause. In some of these cases it's even possible to reword these error messages by removing most of the complicated looking type stuff to something much simpler which then is easier to understand.

This change is hopefully only the starting point to a number of future improvements. I've got a project grant as part of the rust foundation community grant program to work on improving the error messages for trait heavy crates like diesel. Hopefully this will result in other improvements as well. I track this work here. If you hit bad error messages with diesel or any other trait heavy crate, please fill an issue there.

as part of my Rust Foundation Project Grant I'm currently working on improving error messages emitted by rustc for type mismatched based on the usage of trait heavy crates. The general idea here is to provide tools for crate authors to influence at least some error messages by themself. There are quite a lot of places where crate authors can provide much more context than a general rustc heuristic, just based on their knowledge onto how their crate is structured. My project goal is to collect different examples of such errors occurring in practice, classifying them based on what would be required to improve these messages and try various existing ideas on how such a integration in rustc's error reporting system could work in practice. With this post I'm looking forward to learn about cases of bad error messages you encountered in the past. I've created a repository to collect examples here. Please open an issue or even a PR with an example there or report them here inline.

axum does basically ]the trick as bevy](https://docs.rs/axum/latest/axum/handler/trait.Handler.html#impl-Handler%3C(T1%2C)%2C%20B%3E) to emulate variadics and someone already filed this https://github.com/weiznich/rust-foundation-community-grant/issues/2

I already have some diesel specific error examples in the repository. If you remember any specific missing case I'm happy to add it.

This sounds very much like this error message coming from diesel. Basically this happens if rustc is "too" clever and sees that there is an wild card impl for something that might fit. So instead of suggesting that the "real" trait bound is missing it then suggests the bound s on the wildcard impl. Hopefully I'm able to address this by implementing RFC-2397. This would allows you as a crate author to add an hint for rustc to not recommend a specific wild card impl.