5 ms·
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 f
by 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 agoI 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 agoI 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 agoThey'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.