4 ms·

I was surprised not to see Rocket (https://rocket.rs/ https://rocket.rs/) mentioned among the frameworks the author listed; I haven’t used it myself because I _

by paulgb 2y ago

I was surprised not to see Rocket (https://rocket.rs/ https://rocket.rs/) mentioned among the frameworks the author listed; I haven’t used it myself because I _like_ the more unopinionated axum/actix-web, but as I understand it its goals are much more in the vein of what the author wants in a batteries-included framework and it’s been around for a while now.

wslh 2y ago
I 100% agree. I'm just a casual multi-language programmer these days, but I'm familiar with Rocket.
hobofan 2y ago
While Rocket was one of the earliest Rust frameworks that really pushed for good UX (via proc-macros), I think it has largely fallen out of favor in many parts of the community. For a very long time it required nightly Rust versions to build, which is a no-go for many people wanting to use a framework in a production setting. Also for a period of ~2 years it was stuck in a 0.5.0 release candidate limbo where the latest stable released version was significantly lagging behind the rest of Rust web frameworks (requiring nightly; no async support yet). Maybe it will be better now after the 0.5 hump, but in general the development history of Rocket is something that dissuades me from using it when compared to e.g. Axum.
- capitainenemo 2y ago
  When I asked them about that 2 year limbo, they said the release candidate was feature complete, and simply had incomplete documentation (also some plans for a new management structure). So, it wasn't actually lagging, it had that async for quite some time... But yeah, being in a "release candidate" did scare people off.
  - appplication 2y ago
    That is a bit telling on how the maintainers view their users, i.e. unseriously.
    - capitainenemo 2y ago
      Can you elaborate? They seemed pretty responsive to me every time I asked for assistance in the channel... (we'd implemented something in 0.4). If "incomplete documentation" is "unserious" that would be the large majority of open source libraries. Actually blocking on completing it sounds like they were taking the release seriously to me. And I understand it taking a while. No one likes writing documentation.
      - appplication 2y ago
        I’m viewing it from the perspective of being a user who is blocked by a feature or bug fix that has been implemented for 2 years and not released. How do you trust the feature/bug fix cadence moving forward? It’s not like users can’t run release candidates in prod, but there are many reasons not to, and good policy guides against this. I used to be an ardent supporter of Uber’s h3 geospatial library. But we’re running into almost exactly the same issue. Bug impacting us we’re fixed in 4.0 and it’s been stuck in release candidate status for over 2 years. That’s not tenable as a user who is trying to get things done. So now we’re migrating off it entirely.
        capitainenemo 2y ago
        Well. In this case it's almost a labeling thing. You could make an exception for this (maintained) release candidate if in your judgement incomplete documentation (basically rust doc stubs for a significant percentage of the libraries) was (not) a blocker. In some places we were told to never use libraries that weren't 1.0 - obviously that would be bonkers in the rust world. In these things you really have to use your own judgement... I don't feel like their decision to make documentation a release blocker shows disrespect for the users. They were repeatedly clear that it was safe to use and feature complete. They did note the shift from a single man project to a foundation governance took longer than expected and was part of the release as well, but, you know, non-code stuff like that also takes longer.

by paulgb 2y ago

wslh 2y ago

I 100% agree. I'm just a casual multi-language programmer these days, but I'm familiar with Rocket.

hobofan 2y ago

While Rocket was one of the earliest Rust frameworks that really pushed for good UX (via proc-macros), I think it has largely fallen out of favor in many parts of the community. For a very long time it required nightly Rust versions to build, which is a no-go for many people wanting to use a framework in a production setting. Also for a period of ~2 years it was stuck in a 0.5.0 release candidate limbo where the latest stable released version was significantly lagging behind the rest of Rust web frameworks (requiring nightly; no async support yet). Maybe it will be better now after the 0.5 hump, but in general the development history of Rocket is something that dissuades me from using it when compared to e.g. Axum.

capitainenemo 2y ago
When I asked them about that 2 year limbo, they said the release candidate was feature complete, and simply had incomplete documentation (also some plans for a new management structure). So, it wasn't actually lagging, it had that async for quite some time... But yeah, being in a "release candidate" did scare people off.
- appplication 2y ago
  That is a bit telling on how the maintainers view their users, i.e. unseriously.
  - capitainenemo 2y ago
    Can you elaborate? They seemed pretty responsive to me every time I asked for assistance in the channel... (we'd implemented something in 0.4). If "incomplete documentation" is "unserious" that would be the large majority of open source libraries. Actually blocking on completing it sounds like they were taking the release seriously to me. And I understand it taking a while. No one likes writing documentation.
    - appplication 2y ago
      I’m viewing it from the perspective of being a user who is blocked by a feature or bug fix that has been implemented for 2 years and not released. How do you trust the feature/bug fix cadence moving forward? It’s not like users can’t run release candidates in prod, but there are many reasons not to, and good policy guides against this. I used to be an ardent supporter of Uber’s h3 geospatial library. But we’re running into almost exactly the same issue. Bug impacting us we’re fixed in 4.0 and it’s been stuck in release candidate status for over 2 years. That’s not tenable as a user who is trying to get things done. So now we’re migrating off it entirely.
      - capitainenemo 2y ago
        Well. In this case it's almost a labeling thing. You could make an exception for this (maintained) release candidate if in your judgement incomplete documentation (basically rust doc stubs for a significant percentage of the libraries) was (not) a blocker. In some places we were told to never use libraries that weren't 1.0 - obviously that would be bonkers in the rust world. In these things you really have to use your own judgement... I don't feel like their decision to make documentation a release blocker shows disrespect for the users. They were repeatedly clear that it was safe to use and feature complete. They did note the shift from a single man project to a foundation governance took longer than expected and was part of the release as well, but, you know, non-code stuff like that also takes longer.