I noticed the same thing. I would have expected an Arc<Mutex<…>> or something similar for safe concurrency. Not sure what value is delivered by a single threaded, blocking web server.
This framework does thread per connection, but all requests go into a global request queue, and when you call `listen`, it enters an infinite loop which pops requests from the queue and processes them synchronously (one by one).
It sounds like this framework is susceptible to head of line blocking. In my experience, that significantly reduces the utility of any applications written choosing this framework. What’s the benefit being delivered?
No benefit, this appears to be a student's pet project. The submitter has 179k karma and they aren't this framework's author. Either the submitter is unfamiliar with Rust and mistakenly thought this is a real deal or there's some kind of karma abuse/farming going on.
This was posted by its author to /r/rust and then submitted here by someone because if a post does well over there, it often does well over here. That’s not “karma abuse”.
> This was posted by its author to /r/rust and then submitted here by someone because if a post does well over there, it often does well over here. That’s not “karma abuse”.
Except the submitter account in question is actually automating submissions from what looks like Lobsters (based on the timing and posting history). The account owner only seems to post non-automated comments to spam their product. This looks an awful lot like abuse. Or is abuse okay when you perceive it to be beneficial to Rust propaganda?
I just don’t care about karma that much. The first 500 is the only that matters. I find it hard to say that submitting a story that people found valuable is “abuse.”
> when you perceive it to be beneficial to Rust propaganda?
I don’t think this project has a particularly good architecture, nor do I agree with its claims about async rust. I didn’t upvote this submission.