3 ms·
I'm not quite ready to announce it yet, but I'm working on a site that will provide a curated guide to the Rust ecosystem. There are packages that are well supp
by nicoburns 5y ago
I'm not quite ready to announce it yet, but I'm working on a site that will provide a curated guide to the Rust ecosystem. There are packages that are well supported and de facto standards, you just need to know which ones they are (in this case the answer is "axum").
In the future the answer may be go to <SITE-URL>, look up the HTTP server category and either read through a few one-line descriptions or just use the recommended package.
- bad416f1f5a2 5y agoThat is great, and as someone just starting to dabble with Rust I'd love a resource like that. But: no matter how well-curated your site is, and no matter how quality those libraries are, and how well maintained, "batteries-included, in the stdlib, backed by a compatibility promise that the dev team is willing to uphold" carries some serious weight.
- nicoburns 5y agoIt does, but it's not without its downsides either. stdlib modules might end up being abandoned or deprecated because the design can't be changed and it doesn't work well anymore or there are unfixable security issues. Python's stdlib has plenty of such modules for example. Considering that the Rust dev team is mostly volunteers, and many of the most important non-std-lib libraries in the Rust ecosystem are maintained by those same people I feel like there's less of a distinction than there is made out to be.
- htgb 5y agoHow do I get notified when this is available? Sounds great :)
- nicoburns 5y agoIf you email hn@my-hn-username.com then I will be happy to notify you. Otherwise I'll probably submit it here and on /r/rust. Whether it makes the front page, who knows.
- dureuill 5y agosigns that things might not be that easy, i'd say that the answer is rather "actix-web". axum has tokio's momentum, but a much shorter track record than actix.
- nicoburns 5y agoSo "web servers" is a particularly competitive category and there are number of options that are all solid choices. For most categories I have 1 or 2 options with 1 recommended. For web servers I have 6: axum, actix-web, warp, rocket, tide, and poem. With a couple of sentences for each explaining why you might or might not want to choose that option. For me Axum should be the default recommendation because it's the least quirky option. It's also a very thin layer on top of hyper, and built by the tokio team, both of which have a very long track record. Actix-web is a fine choice, but it's a bit of an odd duck in things like not being based on hyper, which makes it a little harder to integrate with the rest of the ecosystem.
- dureuill 5y agothanks, i appreciate the detailed response. I do believe, though, that "least quirky", while definitively important, is not the most deciding factor here. Axum is very young (was announced <1y ago), it has good momentum, is based on hyper and built by the tokio team. On the other hand, it has few actual projects built with it, I couldn't find a guide for it like actix or even Rocket have (it has some documentation in its docsrs documentation, but it is pretty minimal). Crucial questions like how to handle configuration, integration with database, autoreload, are left to the examples at best. I have no doubt that these things will come if the framework matures. I'm just questioning if it should be the default choice right now, as opposed to in a year. (Btw, I would absolutely recommend against Rocket right now, even though API wise it clicked the best with me, until it gets more maintainers and development resumes)
- nicoburns 5y agoThat's definitely a fair point on the documentation for actix-web being better (and rocket, but I agree with you on Rocket's maintenance status being problematic). Once I've got my site into a launchable state, my intention is to open up contributions on the github repo so that we can capture the wisdom of the community from all it's diverse set of perspectives. I definitely don't have all the answers myself.