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

For the database part you might want to checkout a crate that's not based on sqlx as sqlx is known for providing non-optimal performance for the sqlite backend. rusqlite or diesel perform much better for this use case.

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.

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.

As with everything in static type checking, the upfront costs seem high (deciphering type errors can be a bit daunting for both diesel, and to a certain extent dfdx), but I feel like (1) this will get better (especially with the work /u/weiznich is doing), and (2) history has shown the upfront costs are worth it (as evidenced by the takeover of typescript and typed Python).

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.

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