5 ms·

https://github.com/SergioBenitez/Rocket https://github.com/SergioBenitez/Rocket on stable rust finally!

• mrmonkeyman 6y ago
  High speed to the first red light.. the database, IO, network.. I don't see the point of Rust here but whatever floats your boat.
• hellofunk 6y ago
  Interesting. Haven’t used rocket, but I am intrigued by warp since it has a websocket server as well.
• jjice 6y ago
  When I started learning Rust over a year ago now, Rocket was extremely appealing to me. I never subscribe to any GitHub threads that I'm not involved in, except for Rocket on stable. In general, stable proc macros is an awesome step for Rust.
• steveklabnik 6y ago
  https://github.com/SergioBenitez/Rocket/milestone/8 https://github.com/SergioBenitez/Rocket/milestone/8 is what's on the milestone for the next release, I don't know how closely that actually tracks. I'm super excited though!
• rvz 6y ago
  Great news, but it's not even 1.0 yet. Thus, it isn't stable enough for production use. At the moment, I'd rather use something like actix-web instead.
  • neilsense 6y ago
    That's not how versions work
    • The_rationalist 6y ago
      >= 1.0 in semantic versioning universally means that it should be "stable enough"
      • nicoburns 6y ago
        The Rust ecosystem typically has much more conservative version numbers than other ecosystems though, and higher quality standards. There are several very high quality crates with 0.x version numbers.
        • jhasse 6y ago
          They are doing it wrong then.
          • darksaints 6y ago
            One could argue that if you are relying on magic number schemas to decide if a library is stable enough for your usecase, it is you that is doing it wrong.
            • The_rationalist 6y ago
              It's no longer magic number once you follow semver https://semver.org https://semver.org Of course it only offer limited information but this information can tell you whether you should be not confident in it. Pre 1.0 is such a signal.
        • lumost 6y ago
          A fairer statement might be that the rust ecosystem has inconsistent version numbers. I've seen both flawless v.14s and awful v.7s. There are a few ways to figure out the difference like sorting by downloads on crates.io to find packages that are commonly used. There is a curious parallel to the rise of Go which had no versions in their ecosystem as the language was adopted.
      • 6y ago
• ldng 6y ago
  IMHO, it's a shame So Much time has been spent (~3 years ?) on async at the cost of basic features like multipart and CORS. But I understand it could be more fun for the devs :-)
  • wtetzner 6y ago
    I think it makes sense to get your foundation and ergonomics correct before piling on features. Otherwise you end up building features that may need to be completely restructured/redone later.
    • deleted 6y ago
      [deleted]
    • ReactiveJelly 6y ago
      I recently switched from old sync versions of hyper and postgres to the new async versions. [1] It wasn't hard, but yeah it was not fun either. I can only imagine it's worse if you're actually writing the libraries and not just a CRUD app like I am [1] Apparently the postgres crate was a wrapper around tokio_postgres all along and I didn't notice. So to remove a dependency I switched to using tokio_postgres directly
  • Spartan-S63 6y ago
    They've really only spent about a year or so on async support in Rocket. They were waiting for async/await to stabilize and the async runtime story to centralize a bit (though they picked Tokio as the default). Features like CORS are available via third party fairings, but I could see them being incorporated in the future in the `rocket_contrib` portion. I think the goal is to keep the overall framework pretty light and put more things into the `rocket_contrib` portion.