81–90 of 123 posts
I'm not sure the syntax extension specific items are good if the intent is to present this as an argument for moving to Rust from some other language for building such a framework. I'm a bit biased: I'd avoid using syntax extensions that aren't part of the standard, because it adds a point of friction for novice and seasoned Rust developers alike.
Earlier quoted context omitted.
Personally I don't like domain-specific sugared syntax. I prefer clarity above all, especially since I hope to spend the least possible amount of time in the networking domain, and this means I'd otherwise have to relearn the syntax whenever I have to dig into the code again.
When digging into new projects I always find that there's going to be cognitive overhead because of certain abstractions. let always_forward = Route::ranked(1, Get, "/", forward); this is a normal function call, but what does it mean? Is that really better than special syntax that desugars to this code?
I'm not sure the syntax extension specific items are good if the intent is to present this as an argument for moving to Rust from some other language for building such a framework. I'm a bit biased: I'd avoid using syntax extensions that aren't part of the standard, because it adds a point of friction for novice and seasoned Rust developers alike.
Are you talking about the route specification syntax? It doesn't seem much worse than say flask.
But I don't mean in comparison to other languages or frameworks, I mean in generally, as in, I'd avoid creating syntax extensions or using them in any project.
Earlier quoted context omitted.
Are you talking about the route specification syntax? It doesn't seem much worse than say flask.
In this specific case, yes those particularly would be an example. But I don't mean in comparison to other languages or frameworks, I mean in generally, as in, I'd avoid creating syntax extensions or using them in any project.
edit: see replies to my comment. I mistook the Hyper pull request being merged for being in the latest release, but it isn't. Rocket uses Hyper for its HTTP server. So I checked to see if the Hyper HTTP server was really production-ready. Particularly, if it could handle async IO / solve the C10K problem[0]. It looks like Hyper implemented async IO[1], so it should be adequate for production use in this regard. This…
Hyper is not yet async, the preliminary work in the PR you linked to is for a version which has not been pushed to crates.io and is not finished yet.
I am not a web development guy, so this question might seem ridiculous: To me, it always seems that there are a lot of hazards in any web development project, security-wise: A number of attacks, be it injections, XSS, etc. When seeing a new web development framework, I always ask myself: Are the basic security concerns known today addressed? How can I make sure that choosing cool web framework in language X doesn't l…