[HN Gopher] Rocket v0.5: Stable, Async
___________________________________________________________________
Rocket v0.5: Stable, Async
Author : sbenitez
Score : 106 points
Date : 2023-11-17 17:14 UTC (5 hours ago)
(HTM) web link (rocket.rs)
(TXT) w3m dump (rocket.rs)
| imachine1980_ wrote:
| What the advantage over axium(please correct me)
| tomas789 wrote:
| 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.
| awoimbee wrote:
| *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.
| Qwuke wrote:
| 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.
| jaafwasd wrote:
| There isn't one, I migrated to axum and won't go back.
| brundolf wrote:
| 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
| Qwuke wrote:
| 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.
| alberth wrote:
| What's your productivity like using Rust for web development?
|
| Rocket seems like a lot of visual noise vs.
| Laravel/Rails/Django.
| dagmx wrote:
| 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.
| tomas789 wrote:
| 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.
| felipellrocha wrote:
| Can't blame them for trying
| Qwuke wrote:
| 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.
| tomas789 wrote:
| 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.
| nicoburns wrote:
| > 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
| tomas789 wrote:
| You're right. I did not see the announcement [1] before.
| This can possibly make all the difference.
|
| [1]
| https://rocket.rs/v0.5/news/2023-11-17-rwf2-prelaunch/
| Qwuke wrote:
| >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.
| speed_spread wrote:
| 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.
| __s wrote:
| https://rocket.rs/v0.5/news/2023-11-17-rwf2-prelaunch
|
| They address your concern, a foundation is being created
| pzmarzly wrote:
| 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!
| Alifatisk wrote:
| > 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.
| garyrob wrote:
| 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.
| Hamuko wrote:
| I think my biggest annoyance with Rocket is that testing seems
| like an afterthought. I don't think the documentation even
| mentions testing forms.
|
| 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.
| jokethrowaway wrote:
| 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)
| Grimburger wrote:
| > 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.
| couchand wrote:
| 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.
| esmevane wrote:
| 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.
| ufmace wrote:
| > 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.
| spoiler wrote:
| 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?)
| ufmace wrote:
| 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.
| Dig1t wrote:
| 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.
|
| Did it really have to look like this?
| zamalek wrote:
| 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.
| unshavedyak wrote:
| 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.
|
| Personally i love the syntax, but /shrug
| speed_spread wrote:
| 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...
| duped wrote:
| No, the code you're looking at is using a bunch of macros to
| implement an embeded DSL on top of Rust.
|
| For example this: #[get("/echo")] fn
| echo_stream(ws: WebSocket) -> Stream!['static] {
| Stream! { ws => for await message in ws {
| yield message?; } } }
|
| Is not valid Rust code. The `for await message in ws` is
| particularly egregious.
| drewtato wrote:
| 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.
| ufmace wrote:
| 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.
| dkryptr wrote:
| 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.
| lrx wrote:
| What happened to Sergio that had him fall off the face of the
| earth?
| the__alchemist wrote:
| 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.
| norman784 wrote:
| 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.
| Dowwie wrote:
| Wow. They finally made it! Congrats to the team.
| dkryptr wrote:
| I feel kind of bad saying this, but too little too late in my
| opinion.
___________________________________________________________________
(page generated 2023-11-17 23:00 UTC)