4 ms·

I attempted to mimic Go's single flight package myself [0]. It doesn't have support for the asynchronous world but I suppose that could be made possible. I also

I attempted to mimic Go's single flight package myself [0]. It doesn't have support for the asynchronous world but I suppose that could be made possible. I also have to mention bradfitz for providing the initial implementation (I think?) to learn from. It's really quite elegant! Does anyone else think the Rust HTTP ecosystem is becoming increasingly fragmented? I can't keep track of which library is best suited for common operations. Is it a web framework built on hyper? Should I pay attention to tower middleware? Where does tracing fit in? [0]: https://github.com/gsquire/singleflight https://github.com/gsquire/singleflight

nicoburns 5y ago
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.
the__alchemist 5y ago
I'm building a somewhat ambitious web client utility in Rust, and am struggling with this now. I'm using Hyper... and its deps you need it to work with (tokio, futures, hyper-tls). And its begging the question "Is this what I want, or should ditch these, and build a new one using threads". I am not sold on the async paradigm. Some of the Rust OSS community uses it on embedded too, but to me, code using interrupt handlers (or RTIC) is more intuitive. Immediately on viewing the Hyper guide and hello world, the program structure is messier than a normal Rust program. Colors propagate through the program. I am giving this a shot, but am not optimistic this will be cleaner than threading.
- dralley 5y ago
  The point of async isn't that it is cleaner than threading. It can be, but by no means is that guaranteed. The point of async is that at scale threads start becoming expensive. If you don't have high performance requirements under heavy load, async is largely unnecessary.
  - pclmulqdq 5y ago
    Async rust currently isn't well-designed for pushing throughput to its limits, though. You really need a lot of batching and very few uses of atomic ops on your CPU to get to extreme throughputs, and Tokio doesn't generally give you great batching. I have also found that good concurrent data structures for Rust are a lot harder to find than other languages.
    - DenseComet 5y ago
      Stock Tokio is tuned towards the general set of applications, attempting to make things work well out of the box, while being ergonomic to use. But, this isn't set in stone. There are knobs and patterns that can be used to really squeeze out performance, as seen with Actix Web, which is based on Tokio [1]. [1] https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
      - 5y ago

nicoburns 5y ago

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.

the__alchemist 5y ago

I'm building a somewhat ambitious web client utility in Rust, and am struggling with this now. I'm using Hyper... and its deps you need it to work with (tokio, futures, hyper-tls). And its begging the question "Is this what I want, or should ditch these, and build a new one using threads". I am not sold on the async paradigm. Some of the Rust OSS community uses it on embedded too, but to me, code using interrupt handlers (or RTIC) is more intuitive. Immediately on viewing the Hyper guide and hello world, the program structure is messier than a normal Rust program. Colors propagate through the program. I am giving this a shot, but am not optimistic this will be cleaner than threading.

dralley 5y ago
The point of async isn't that it is cleaner than threading. It can be, but by no means is that guaranteed. The point of async is that at scale threads start becoming expensive. If you don't have high performance requirements under heavy load, async is largely unnecessary.
- pclmulqdq 5y ago
  Async rust currently isn't well-designed for pushing throughput to its limits, though. You really need a lot of batching and very few uses of atomic ops on your CPU to get to extreme throughputs, and Tokio doesn't generally give you great batching. I have also found that good concurrent data structures for Rust are a lot harder to find than other languages.
  - DenseComet 5y ago
    Stock Tokio is tuned towards the general set of applications, attempting to make things work well out of the box, while being ergonomic to use. But, this isn't set in stone. There are knobs and patterns that can be used to really squeeze out performance, as seen with Actix Web, which is based on Tokio [1]. [1] https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/
    - 5y ago