So glad to see 0.5 out of release candidacy! I really appreciated how async functions and event streams were handled in 0.5, and just seeing this version land will make it so much easier to justify using Rocket in production.
I still think Rocket is the most concise web framework for Rust after 5 years now of using it in projects and even newer frameworks, and also is one of the best examples of how ergonomic you can make frameworks and DSLs in-general using Rust's type system.
For those wondering what makes it so different, the "batteries included" approach really differentiates it from other web frameworks in Rust, and it reduces the total amount of boilerplate you need to setup for simple middleware, streams, and security just about everything you need to do for simple web services.
My Rust (actix but similar to rocket syntactically) servers are almost 1:1 code similarity to my Python (flask/django) in practice. The extra verbosity tends to only be for multi threaded state management but even then I can generally wrap stuff in an Arc RWLock and be fine.
So Rust code may look jarring in-general compared to dynamic languages, and this is because Rust is a strongly typed language, but on top of that its type system also gives guarantees around data races that other typed languages don't prevent. So most Rust frameworks seem "noisy" when doing more than Hello World in my experience.
In my experience Rocket is intentionally less "batteries-included" than newer versions of frameworks like Rails and Django (especially around querying databases), but provides an opinionated approach that has minimal boilerplate in the same spirit as those frameworks. If you just want to write a Rust web service and get to the business logic, Rocket is a great choice especially if you're coming from another language.
It's a compromise. Many of the things that are runtime errors in those three will be compile time errors in Rust, but the cost of that is that you'll have those details in your face/code all the time.
I've found that chatgpt helps a lot in making Rust more approachable, and the benefits of those more easy going languages are diminishing due to that.
I was developing a fairly large web app with Rocket 0.4 (released 2018!) and it started as a good experience, but then I was burned by the lack of support for multipart forms (i.e. file uploads), poor async, no option to listen on unix socket (required by my hosting provider's proxy) and long compilation times (not fully fault of Rocket, Rust compiler team has done a lot to speed up compilation since then). In the end, I found hacky solutions for all these issues, but I learned that perhaps Rust is not the right choice to make full-stack web apps and rewrote everything to Laravel (PHP) and Vue (JS).
Past me would have loved this update. Thank you in his name!
I tried rocket back then and reached similar conclusions - then I just picked the most popular choice (actix at the time). Actix had its highs and lows but always delivered.
Nowadays I'm on axum (mainly because the API is nice and because it feels like the community is moving in that direction) and the experience is great.
I'm working to rewrite my node.js and python service to Rust to simplify my stack and take care of unreliability and hard to debug occasional bugs.
And I'm also adopting leptos to do frontend development (moving from solid.js - which is already pretty nice)
> feels like the community is moving in that direction
Likely unpopular opinion here but the Rust community is incredibly fickle and tends to attract "shiny new thing" types. I'd be very cautious hitching your wagon to whatever horse they are championing in 202X. Use what is best for your needs.
In this case, "community is moving in that direction" means that over the last 3+ years, a significant amount of middleware and tooling has grown in the Tower ecosystem, which Axum is based on. So the network effect is the draw here, not a hype cycle.
The problem I ran into with Rocket was that because it had stagnated for so long it was incompatible with currently maintained versions of some of the dependencies (I want to say diesel, but I could be wrong).
I'm glad to see that it's been picked up again and 0.5 has been released. I got used to Axum (and rather like it), but in some ways I thought Rocket was friendlier to use.
Yes and no. On the one hand, you want to pick dependencies that have staying power. On the same hand, having mindshare is necessary for the durability.
Hard to resolve the core issue here, since it's ultimately social rather than technical.
How's your experience with Leptos so far? I gave it a try over a weekend for my pet project, felt that it's not ready for prime time yet, so decided to go ahead with Dioxus (which doesn't mean that it's more stable or anything).
> I learned that perhaps Rust is not the right choice to make full-stack web apps and rewrote everything to Laravel (PHP) and Vue (JS).
I fully agree with you on this one and people have been saying this for a long time now, Rust and its kind has its place. Full stack web framework is not one of them.
His point seems to have been that while version .4 had those missing pieces, the problems he mentions have now been addressed in .5. Maybe Full stack web with rust is more imaginable now. In any case, I plan to try it.
> perhaps Rust is not the right choice to make full-stack web apps
This is a good step, but I still wonder if this is the case. I do like some aspects of writing webapps in Rust, but the ecosystem for serious web apps is still woefully immature. There just aren't battle-tested and well-supported solutions for many critical things, including tracing, monitoring, security, etc.
The `tracing` ecosystem is IMO pretty good, and even works with Sentry for various frameworks (well largely it's all tower based anyway)
Not sure what you mean by monitoring. What do you expect (and do you have any examples where other languages provide monitoring solutions?).
Security wise, I've not had any issues finding crates for specific things I needed either, but security is a broad domain (so what did you find lacking in particular?)
Well that's the thing about it - it mostly appears to be there, but often proves to be immature. Meaning it technically works, but most of them are inflexible, single-person projects that occasionally completely redo their API. They work their way, and good luck if you want to do anything slightly different, and unpredictable things might happen if you try to combine several things together. Not exactly confidence-inspiring to base an important production web app upon.
Tracing appears to work, but I was trying to get OpenTelemetry trace IDs into our log messages with a custom layer, which I needed anyways to match our standardized output format that every other web app in every other language can be set up to log as. I still haven't figured out how to get the current OTel TraceID in the context of Layer.on_event - there's like 4 different ways that look like they ought to work, but none of them actually do.
I wanted to set up Prometheus metrics as well. I hadn't dug too deep into that one, but it didn't seem clear what the best / most mature crates were for that or how they'd integrate with everything else.
I was able to put together a Tower Layer for our custom internal request signing system - good on them for having a standardized middleware system, though it'd be nice if more of the Rust HTTP ecosystem actually used it. I think Rocket still doesn't. It was also rather a struggle to figure out how to do things I would expect to be basic, like process the request body in the context of a Layer middleware while still leaving it available to downstream Layers and the final request handler.
Tracing is extremely opinionated in the name of performance. In practice this means you can end up in a position where you've got to take some huge chunk of code to change a small part.
Hate to say that but I’d be happier if this never happened.
I think many newcomers think that Rocket is “the web framework” in Rust. And if author goes silent again they will be let down. It casts kinda bad shadow on Rust community but we have better alternatives.
I'm not sure I understand this - I think having different options for web frameworks is great for Rust! Actually, it's probably more useful for Rust than other languages because Rust ends up being used by such a different range of developers and applications, and each framework ends up having such different opinions and providing different levels of abstractions.
Rocket was created by Sergio Benitez. He is almost exclusively the only contributor to the project. Not because people don't want to contribute to it, but because the author wants to have it as sort of his child's brain. And there is nothing bad about that. But recently he said at a conference (as I read on Reddit) that he does not have much time anymore to invest in its development. That means that there is probably no bright future for Rocket. Especially because a batteries-included framework like this takes so much effort to develop and polish.
I think that a website or API backend is the first project for many newcomers to Rust. It would be better for them to have first experience with other frameworks such that they are not let down by Rocket as it might cast a bad light at the whole ecosystem.
Rocket looks tempting because a/ it has a nice website b/ it looks feature complete c/ it is similar to Django/Flask which might make it more familiar d/ other web frameworks don't have particularly appealing documentation.
>Rocket was created by Sergio Benitez. He is almost exclusively the only contributor to the project. Not because people don't want to contribute to it, but because the author wants to have it as sort of his child's brain.
I've talked to Sergio before in-person and got a completely different take of how he views contributions, but also, apparently he's explicitly trying to democratize Rocket's governance as part of this new stream of updates. I think the 0.5 release is a good sign he's doing his best to maintain his flavor of framework despite time constraints.
>I think that a website or API backend is the first project for many newcomers to Rust. It would be better for them to have first experience with other frameworks such that they are not let down by Rocket as it might cast a bad light at the whole ecosystem.
I guess your experience with it being a let down is contrasted with mine of how the 0.5 release candidates have been great to make web apps with - especially for new comers who want to experience a very ergonomic "secure by default" web framework in a language that makes major promises about safety, but also where encountering new behaviors with the Rust compiler can be an impediment from writing anything in the language.
>Rocket looks tempting because a/ it has a nice website b/ it looks feature complete c/ it is similar to Django/Flask which might make it more familiar d/ other web frameworks don't have particularly appealing documentation.
Perhaps we should spend some time as a community to make a website showing some examples and pros and cons of the various web frameworks. A good example to show newcomers that might help them choose a framework is demonstrating error messaging that some macros in Rocket emit vs a similar error in Axum that wouldn't ever have an error. Or showing them tower middleware crate ecosystem vs the middleware ecosystem in Rocket (or which parts of rocket that don't even need middleware or setup vs Axum) - not by hoping that the developer puts less effort in the project or kills it, which takes the options away from the community.
If I started on a website that does that, would you be willing to provide me some feedback? I'd be happy to take on that burden if there's a lack of a single, good resource for it.
I'm a full-stack developer that started my work on Bend using Rocket and then migrated to Axum. Would be very happy to contribute/be a part of a community initiative like the one you describe
> He is almost exclusively the only contributor to the project. Not because people don't want to contribute to it, but because the author wants to have it as sort of his child's brain.
This has been the case, but the announcement of this release also came with the announcement of the creation of a non-profit foundation to own the Rocket project, and the opening up of development / maintainership to the community
This is the kind of problem that can solve itself, if enough people adopt a project and depend on it, its maintenance can be organized. It helps if the original author is willing to help with the transition to a community-maintained project, which seems to be the case with Rocket.
I like the idea of Rust, its technical merits etc, but good lord this language has some crazy weird and intimidating syntax. I read the code snippets and am just confused as heck.
Once you get over the initial hurdle, the syntax is extremely consistent and "guessable." By which I mean, once you know the basics you can guess how to do things that you have never done before - and if it doesn't work there's probably a pending RFC that matches your expectations.
For example, you might learn that you can do `if let Some(foo) = option` to check if some option is Some, but to also extract the value from it. Now you might guess that the let conditionals might work elsewhere, and you'd be right! `while let Some(line) = reader.read()` totally works.
Now compare this to the likes of C, where for example `break` appears in a `switch` for some bizarre reason (yes, I know the actual reason) and `case`s don't have braces.
This is definitely not helped by Rocket. Even I, knowing Rust well, don't enjoy the way Rocket puts so much logic into attribute macros and function signatures.
It really depends on where you're coming from and if you understand the problems Rust is trying to solve. Rust is a strongly typed language that promotes explicitness over ambiguity, making actual application code look quite different from JS or Python which provide a lot of shortcuts but also have plenty of hidden trapdoors.
Some say that Rust naming conventions actually uses snake_case in variables because each underscore is a little trapdoor that's made apparent so you don't fall in it!
Being mainly imperative with some functional and OO niceties, it's also much less weird than many other languages. Try reading some Haskell or Erlang before judging how weird a language looks...
I'd be curious how you rewrite the syntax to have the same features but less syntax choices. Especially if it was made in the same way, organic evolution over the years.
I suspect it might look different. Not better or worse, just.. different. Same core complaints.
Now what if it was written from scratch today? That would prob miss a lot of the warts you don't like. But it still represents a lot of complexity in all the features the language presents, so it wouldn't be Python - for sure.
Very cool to see this finally go out, and especially the new Foundation. I have to wonder though if it's too late though. I gave up waiting for a new Rocket release years ago and have been doing what Rust web work I've been doing on Axum instead - the integration with Tower is very nice.
Agreed. When I first considered porting small APIs over to Rust, Rocket appeared to be the most popular besides Actix. Axum hadn't even came out (it came out a month later and we ended up using it even though it was in its infancy). It's pretty unfortunate because Rocket could be amazing but the lack of updates killed it. See you guys in 5 years when v0.6 comes out.
Maybe one day I'll use Rust for backend dev. Everyone wants something different, but I'll use Django, and deal with Python's messiness until we get a Rust framework that has a high-level ORM, built in auth, admin, etc. And would prefer no Async.
Coming from normal dev work myself, I’m drawn to dotnet nowadays. If you ever make the chance, it’s real easy to get started and do what Python does in aspnet, scripting, whatever.
Looking forward to this hopefully final big upgrade on my 20k LOC web service[1]. The upgrade from 0.4 to the first rc of 0.5 was a slog, but I've already upgraded to 0.5-rc.4 so this should hopefully be comparatively painless.
It's sad that it took to long to reach this state, a few years in beta and now it's out, if it didn't were for this it would been my framework of choice for web development in rust, it is very nice and all, but the support and lack of ways for the community to contribute killed the project for me.
Now that Actix and Axum are there, I would not go back to Rocket. But still kudos to the maintainers and the new direction of the project being now in process to be owned by a non-profit. I'd hope that the community is still interested in it and grow, we need more options in the space and Rocket being different that the others is also a good thing.
I'd say it's more of an opinionated approach to a web framework, which reduces boilerplate on a lot of simpler applications. In order to facilitate this, it ends up creating more of a Domain Specific Language (DSL) using macros and types for Rocket, which can be harder to manipulate in ways you might expect as a Rust developer.
Axum on the other hand tends to avoid macros and uses the type system in "more composable" way with other Rust crates, and while still providing a concise way to create web apps, has resulted in more boilerplate to hit the ground running in my experience.
*axum
I migrated a rocket project to axum 1~2 years ago, due to rocket being dead at the time.
Both frameworks contain all you need to build an API really.
But personally I found that:
Rocket is easier for beginners, and once you know what you're doing, Axum is cleaner and better integrated in the ecosystem.
It probably feels more familiar if you are coming from the world of Python’s Django or Flask. Other than that Axum is very likely a better choice for all use cases.
Wow, I'd honestly assumed Rocket was dead. Glad to see it continue! It takes a pretty different approach from the other Rust web frameworks (much more opinionated and all-inclusive), so it's great to have more diversity in the space
I still think Rocket is the most concise web framework for Rust after 5 years now of using it in projects and even newer frameworks, and also is one of the best examples of how ergonomic you can make frameworks and DSLs in-general using Rust's type system.
For those wondering what makes it so different, the "batteries included" approach really differentiates it from other web frameworks in Rust, and it reduces the total amount of boilerplate you need to setup for simple middleware, streams, and security just about everything you need to do for simple web services.