Hacker News new | ask | show | jobs
by the__alchemist 1566 days 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.
1 comments
dralley 1566 days 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.

link
pclmulqdq 1566 days 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.
link
DenseComet 1566 days 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/

link
pclmulqdq 1566 days ago
I'm not sure why you can't make a framework tuned towards a "general set" of applications that offers batching and run-to-completion semantics. As far as I can tell, the biggest problem with this is the semantics: async/await and futures models of async programming make it hard to figure out how to produce batches.
link