Rocket v0.5: Stable, Async(rocket.rs) |
Rocket v0.5: Stable, Async(rocket.rs) |
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.
Rocket seems like a lot of visual noise vs. Laravel/Rails/Django.
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.
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.
Past me would have loved this update. Thank you in his name!
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)
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.
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.
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.
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?)
I also need to hack around a bit to ship templates, since I want to distribute my app (with a Rocket server in it) as a single executable.
My biggest gripe is that when a template doesn't compile the error messages are quite useless, but other than that it is great.
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 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.
They address your concern, a foundation is being created
Did it really have to look like this?
[1]: https://notado.app
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.
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.
A major pain in Rust ecosystem, where few libraries feel like actually having a 1.0.
For example this:
#[get("/echo")]
fn echo_stream(ws: WebSocket) -> Stream!['static] {
Stream! { ws =>
for await message in ws {
yield message?;
}
}
}
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.
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 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.
Personally i love the syntax, but /shrug
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.
custom layer
Prometheus metrics
Maybe shiny new thing people enjoy fixing that stuff but I personally like stability in my frameworks.
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.
Hard to resolve the core issue here, since it's ultimately social rather than technical.
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.
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