4 ms·

I actually think it's gone through a period of fragmentation, and is now heading back towards a more unified ecosystem: - There was a split between tokio and a

I actually think it's gone through a period of fragmentation, and is now heading back towards a more unified ecosystem: - There was a split between tokio and async-std asynchronous executors, but the ecosystem now seems to be coalescing back around tokio. - There was weird split where Hyper was the de facto http library, but the best web framework was actix-web which wasn't based on hyper. But now there is Axum, an official Tokio project that is good enough to generally recommended for all web projects, and looks to be the project with momentum going forwards. - Tracing is really the only game in town when it comes to asynchronous logging, and again is part of the Tokio project. Tower is a bit of a weird one. It's a very general middleware layer which I think does actually provide a very good abstraction. But that abstraction is quite complex, and learning it is in many cases trickier than doing an implementation from scratch. I suspect it might come to play a bigger part in the Rust ecosystem at some point, but for now I'd ignore it.

d4mi3n 5y ago
Coming from the Ruby ecosystem, a lot of this played out similarly to how the Rack[1] middleware conventions developed in the early Rails v1 and v2 days. Prior to Rack there was a lot of fragmentation in HTTP server libraries, post-Rack everything more or less played nicely as long as libraries implemented Rack interfaces. I don't write Rust professionally, but it was a bummer seeing that this seems to be a place that was figured out (painfully) in ecosystems used heavily for web development--Javascript and Elixir have their own Rack equivalents[2][3]. I hope that Tower plays a similar role to unify the library ecosystem in Rust. 1. https://github.com/rack/rack https://github.com/rack/rack 2. http://expressjs.com/en/guide/writing-middleware.html http://expressjs.com/en/guide/writing-middleware.html 3. https://github.com/elixir-plug/plug https://github.com/elixir-plug/plug
- nicoburns 5y ago
  JavaScripts “Rack” equivalent is actually a library called “connect”, which express used to use under the hood as it’s middleware layer. The fact it doesn’t anymore is why I’m a little pessimistic about Tower, but it’s good to hear this has worked in other ecosystems.
ibraheemdev 5y ago
> There was weird split where Hyper was the de facto http library, but the best web framework was actix-web which wasn't based on hyper. actix-web, like hyper, is built on tokio, so I'm not sure why you see this as a weird split. The underlying HTTP server is not something you generally interact with. actix-web even _uses_ hyper (the h2 crate) for HTTP2.
- nicoburns 5y ago
  For me the weird part was when I needed to use an http client within my http server and I was pushed towards actix-http rather than reqwest.

d4mi3n 5y ago

Coming from the Ruby ecosystem, a lot of this played out similarly to how the Rack[1] middleware conventions developed in the early Rails v1 and v2 days. Prior to Rack there was a lot of fragmentation in HTTP server libraries, post-Rack everything more or less played nicely as long as libraries implemented Rack interfaces. I don't write Rust professionally, but it was a bummer seeing that this seems to be a place that was figured out (painfully) in ecosystems used heavily for web development--Javascript and Elixir have their own Rack equivalents[2][3]. I hope that Tower plays a similar role to unify the library ecosystem in Rust. 1. https://github.com/rack/rack https://github.com/rack/rack 2. http://expressjs.com/en/guide/writing-middleware.html http://expressjs.com/en/guide/writing-middleware.html 3. https://github.com/elixir-plug/plug https://github.com/elixir-plug/plug

nicoburns 5y ago
JavaScripts “Rack” equivalent is actually a library called “connect”, which express used to use under the hood as it’s middleware layer. The fact it doesn’t anymore is why I’m a little pessimistic about Tower, but it’s good to hear this has worked in other ecosystems.

ibraheemdev 5y ago

> There was weird split where Hyper was the de facto http library, but the best web framework was actix-web which wasn't based on hyper. actix-web, like hyper, is built on tokio, so I'm not sure why you see this as a weird split. The underlying HTTP server is not something you generally interact with. actix-web even _uses_ hyper (the h2 crate) for HTTP2.

nicoburns 5y ago
For me the weird part was when I needed to use an http client within my http server and I was pushed towards actix-http rather than reqwest.