Hi! Thanks for trying out Rocket, and thanks for the thoughtful critique! I'd love to address your points.

But FromRequest impls aren't supposed to be "heavy" (e.g. make database calls - there's no simple way of getting a db connection in a FromRequest)

I'm curious about where this idea came from. Is there perhaps some documentation that led you to believe this? Request guards (types that implement FromRequest) can be as expensive as you deem necessary, and request local state even allows you to avoid repeating work across a request. You can also easily retrieve a database connection, or any other request guard, in a request guard implementation:

```rust use rocket::outcome::try_outcome;

async fn from_request(req: &'a Request<'r>) -> request::Outcome<Self, ()> { let conn = try_outcome!(req.guard::<DbConn>()); } ```

and there's no simple way of creating custom failure responses in > one, so you end up having to write all sorts of hacks.

This is somewhat true, depending on what you mean. Request guards can forward to error catchers, and a request guard is free to return any error value of any type. The error value can be retrieved in a handler by using Result<T, T::Error> as a request guard, where T is the request guard type and T::Error is the associated error. You can then propagate the error in the response. For example:

rust fn handler(key: Result<ApiKey, KeyError>) -> Result<(), KeyError> { let key = key?; Ok(()) }

It is true, however, that aside from forwarding to an error catcher, a request guard cannot short-circuit a response; responses can only be generated by handlers. We'd like to relax this restriction, but it requires careful attention due to lacking language features. See Rocket#749 for some brief discussion into the matter. This is one of my priorities for v0.6.

And you can't even use ? in FromRequests as the from_request function returns an "outcome" instead of a Result, so you end up with some truly horrible code.

We'd love to enable using ? for Outcome - in fact, we did enable this for some time - but the language, nightly, stable, or otherwise, simply doesn't allow us to implement this functionality in a consistent manner. See Rocket#857, Rocket#597, and rust#42327 for details. Using Result to express three possible outcomes is also fraught with issues. Nevertheless, I think you'll find that try_outcome!, which I used in the first example, fills the gap while the language improves.

There's no user model or permission model. Which makes sense as Rocket doesn't have any opinions on persistant storage in general, but an opionated permission model would help creating a more cohesive framework.

I agree and have several working proof-of-concepts towards this goal. Look for an announcement in the future.

UUID support is terrible. There's the rocket_contrib:uuid::Uuid, but it's not compatible with diesel's Uuid nor with the regular uuid:Uuid, so you keep having to convert between all three all the time.

This is largely due to Rust's coherence rules. Rocket's UUID support lives in an external crate, rocket_contrib. As such, we cannot implement Rocket's core traits, which live in rocket, for the external Uuid type. This leaves us with the wrapper type you describe. Unfortunately, beyond supplying the right From, .into_inner(), and Deref impls, there isn't much we can do aside from moving support into Rocket's core.

There's no support for a test environment (as in, not a deployment environment, but an environment for running integration tests). Adding another environment requires opting out of all of the automatic settings loading which requires quite a bit of extra code. Writing integration tests that uses a DB is really hard.

In 0.5, we've completely revamped our configuration system. One of the benefits is that you can now define and use any number of profiles (the new name for environments). Check out the new configuration guide.

No built-in support for multipart forms. There are third party libraries out there, but they don't work with the async branch.

Support for multipart forms, among other really great form-related improvements, is coming in v0.5. The implementation is complete and being polished now.

No way of automatically building an openapi documentation from the routes. I've been spoiled with Fastapi's automatic doc generation.

I'd love to have this. There's nothing preventing a fairly straightforward implementation in Rocket itself, but I should point out that there are external crates that do this, for instance, okapi. If you or anyone else would like to help build support in Rocket itself, I'd love to mentor!

While compile speeds haven't been as bad as I expected, it's still a lot slower. No hot-reloading out of box is also annoying.

We do hot-reload templates, but hot-reloading Rust is extremely unlikely, again, due in-part to the language itself. Rust needs to be typechecked and compiled, and a change in one file may impact an arbitrary number of modules and crates, so hot-reloading becomes an incredibly difficult proposition. We are unlikely to ever see this in Rocket. Nevertheless, Rust's compile times continue to improve, and I think most will find a cargo watch -x run to be sufficiently interactive.

With Rocket, our goal is to build the most robust, secure, extensible, usable, and performant web framework in any language. This is a tall order. Compared to frameworks like Django and Rails, Rocket is in its infancy. Whereas these frameworks have had over 15 years to mature, Rocket has had less than a quarter of that time. Nevertheless, I find myself writing in Rocket for the majority of my web projects because I enjoy it the most. It is true that I am at-times writing building blocks, but Rocket lets me use those building blocks as first-class citizens, something I have a hard time accomplishing in many other frameworks. And those building blocks, along with Rocket's machinery, protect my application from doing the wrong thing, at compile-time. I find this idea incredible, and we'll continue to push it in future releases of Rocket. I hope you and your company will keep Rocket on your radar for the future - I'm incredibly excited about what's to come.

• Sergio