I just want to add that I really like where Tokio is going. The architecture seems well-thought-out and exactly the sort of thing I'm looking for. There's only one problem though...
It's still under construction!
Every day something new breaks, haha. Whether it's tokio-middleware with the "what was I thinking?" patch:
The good news though is that it is obviously being worked on--heavily. The Rust ecosystem is so new that it feels a bit like we're in the Wild West. Someone comes up with a decent way to do something and then after a bit of ecosystem evolution we're back to the drawing board since, "there's a better way."
This is all very good because it means that the Rust ecosystem is evolving rapidly. It also means that developers are productive enough in the language that entire frameworks can be re-written from scratch in a reasonably short amount of time. I think it's a good demonstration of how effective the language is overall at its goal of improving productivity (as far as systems programming languages go).
> The Rust ecosystem is so new that it feels a bit like we're in the Wild West.
This is pretty normal for an ecosystem at Rust's stage of development. Ecosystem development is always something of a monkeys-on-typewriters effect and if you continuously have major disruptions in the language, you wind up with Javascript Fatigue.
What I'm particularly impressed with in Rust is the core team's leadership. I'm looking forward to Tokio because I think it's likely to have Rails-like dominance over the ecosystem. This is exciting because it gets us monkeys all pointed in the same direction instead of writing another postgresql client because existing ones don't support the current flavor of event loop that I'm using. Getting to the point where we can snap a bunch of pieces together and have a network service is huge for office advocacy. I think it was a key factor in Ruby's wins over the more established Python web community when observing from the Python side.
I'm also pleased that the Rust core team is focused on my pet areas of improvement: editor support, impl Trait, and async network services.
I'm one of the persons waiting for a stable tokio so badly. I have many use cases for this in my Rust projects that are either currently doing async io so-so or doing stuff like firing http requests in sync using the tools available. The situation in hyper land is not very cool at the moment, master being async but requiring you to write the callbacks, stable using too old openssl and the tokio branch not compiling.
With tokio I could unify my code base and make the code simpler and easier to follow.
It's still under construction!
Every day something new breaks, haha. Whether it's tokio-middleware with the "what was I thinking?" patch:
https://github.com/tokio-rs/tokio-middleware/commit/78210757...
(seriously, click that link it's funny)
...or today's fun:
https://github.com/tokio-rs/tokio-minihttp/issues/12
The good news though is that it is obviously being worked on--heavily. The Rust ecosystem is so new that it feels a bit like we're in the Wild West. Someone comes up with a decent way to do something and then after a bit of ecosystem evolution we're back to the drawing board since, "there's a better way."
This is all very good because it means that the Rust ecosystem is evolving rapidly. It also means that developers are productive enough in the language that entire frameworks can be re-written from scratch in a reasonably short amount of time. I think it's a good demonstration of how effective the language is overall at its goal of improving productivity (as far as systems programming languages go).