The recent 0.5 release was discussed 5 days ago here: https://news.ycombinator.com/item?id=38306540

After using Rocket in production for a year now. I'd really recommend Actix Web. Don't get me wrong, Rocket has some really nice features and good UI, but a couple things have proved to be real pain points:

- Middleware ("fairings" in rocket parlance) can't respond to requests. This means your access control has to be replicated on every route as a guard.

- Guards can result in errors (for example, if the request doesn't have a valid Auhorization header), but you can't set the response body without a nasty workaround that causes other issues [1]

- Guards also have tricky performance gotchas. When multiple handlers match the same route, rocket will try them all in priority order. Often these variants have the same or similar sets of guards, but guards don't cache by default. Doing your own caching gets tricky especially in the presence of workaround [1].

All this to say, Rocket works well, but it has some unique problems that come from its early design decisions (e.g. the guard error messages which has an open issue) and some from ongoing decisions (i.e. the project seems to committed to the fairing model over standard middleware).

Many of these problems are fixable by community members like you, but actix avoids several of these and has a larger developer base. I've heard good things about axum and the docs look great but I haven't had much experience so I can't offer a strong recommendation.

[1]: https://github.com/rwf2/Rocket/issues/749#issuecomment-91629...

I'm using Rocket for a small production application for my PhD project. One supervisor recently took over the project and asked me where he could connect a log stream to detect crashes. I said: "I don't know. I never have crashes". At the same time, maximum memory consumption is about 15 MB (3% of 512 MB) and CPU load 0.1% on a Starter instance on Render.

So credits to the Rocket maintainers for making Rocket such a reliable piece of software!

From a quick glance it seems still vulnerable to trivial slowloris’ing D:

Is anybody actually exposing their rust-based websites to the internet? I want to, but it seems that for some reason every rust web framework keeps TCP connections open _forever_, meaning that even with file descriptors bumped to 64000, my web server runs out of FDs and needs to be killed and restarted every 3 hours or so. The standard advice seems to be “don’t do that, put your rust app behind a reverse-proxy written in C or Go, and let the proxy handle the complexities of TCP”, but it seems so sad to add an extra layer of latency and complexity just to close idle connections ;(

And here are the changes for the recently released v0.5: https://rocket.rs/v0.5/news/2023-11-17-version-0.5/

Rocket's documentation and overall 'dev experience' are very pleasant. In the past, I felt like I was making a significant tradeoff when using Rocket over more actively developed frameworks (Axum and Actix Web). With v0.5 (finally) coming out, and the Rocket Web Framework Foundation, that feels like much less of a concern. A great example of Rocket in use is the official Rust website, which is open source.

> While Rocket is still in the 0.x phase, the version number is purely a stylistic choice.

> If you're coming from a different ecosystem, you should feel comfortable considering Rocket's v0.x as someone else's vx.0.

I didn't think there were libraries in the Rust world that objected semver. It seemed quite ubiquitous since it's built into Cargo. Very disappointing.

I know they recently released 0.5 which finally works with stable Rust, among other things, but it really is "too little, too late" for me, as I've since moved onto first Actix Web then onto Axum. There is something to be said for rapid development rather than waiting to release big releases every other year. This is similar to the discussion of Elm a few days ago, where I left it because we needed critical bugs to be fixed and features to be added, so we migrated to a framework that does have such a rapid development cycle.

Rocket is a delight. Been using it for a year now and the docs and dev experience and stability are all exceptional.

Request Guard Transparency[1] is something I’ve only seen in Rocket:

> When a request guard type can only be created through its FromRequest implementation, and the type is not Copy, the existence of a request guard value provides a type-level proof that the current request has been validated against an arbitrary policy. This provides powerful means of protecting your application against access-control violations by requiring data accessing methods to witness a proof of authorization via a request guard. We call the notion of using a request guard as a witness guard transparency.

Basically your endpoints can require access to a protected service via a parameter and you’re guaranteed that your code will only execute for valid&authorized requests. For example, imagine a UserService and a TeamAdminService, each with their own methods appropriate for their user type. Request guards are used to validate the request headers and database entries are correct before constructing these services. And since you can only construct them from a request, simply having a service listed as a parameter in your endpoint guarantees that the proper access control has be enforced before your code runs.

We’ve structured our app so that every sensitive operation goes through these services, thereby sidestepping entire classes of security concerns and missteps. I sleep better as a result and our security reviews are much more enjoyable.

I’d love to see this discussed more and adopted by more frameworks.

[1]: https://rocket.rs/v0.5/guide/requests/#guard-transparency

What got me interested in Rocket was from this talk (a great talk btw): https://youtu.be/lBQHrj6vwAo?feature=shared&t=1934 (A Case for Oxidation)

The main selling point for me was that Rocket made security threats (XSS, SQL injection etc) impossible by guarantees which was a bit mind blowing imo. It is a bit like database guarantees which is insanely useful as an application grows. Is this still the case with Rocket and if so, how come it's not all over their web page as the unique selling point? I mean, security is getting more and more important and if we can solve many preventable security threats permanently by a technical choice this seems like the obvious way to go for the future.

I mean, Rust is fast and secure and makes my software "unhackable" for the price of a bit slower development? Seems like an obvious choice then.

When I browse their website, I don't understand if this is still the case and coming from a php/node background this would be the main driver for me since the language performance is very rarely a concern of mine and coding rust is.. slow and requires a lot of learning because of the weird syntax that makes me think about memory when I don't really care.

What I also really, really like about Rust, Go and other similar languages is that the deployment option that becomes available. Just deploy a single binary file. That is super simple and awesome. But the one thing that made me look away from Rust is the foundations weird rules and new draft that you cannot use the word Rust in urls, courses etc and if you like guns?

I don't know how it's been developing so far but the Rust foundation seems to do some crazy stuff that makes it hard to trust.

Only speaking to the thread here, I really wish people would stop acting like memory / thread safety and correctness are the same thing.

Never thought I would see the release of v0.5. Congrats to all the maintainers!

Can’t wait to play with this!

introducing a new term when an established term exists seem to add another overhead. "but bro, you'll get used to it in no time." i hear you, buddy. it just leaves a bit bad taste.

anyway, i can't believe i say this, i think dhh's words on tradeoff between squeezing performance out of an ecosystem and "just throw more hardware on it" is a tradeoff that i can clearly choose.

Or, just use PHP… /s