4 ms·

Is there popular Rust web server which uses just threads with no async stuff?

by vbezhenar 4y ago

mfashby 4y ago
Rocket.rs I believe
- DoubleFree 4y ago
  Rocket is moving towards async as well
  - 0x457 4y ago
    Rocket is not moving anywhere right now. 0.5 supposed to be async, but it's delayed more than a year because maintainer doesn't have time.
  - Grimburger 4y ago
    You don't have to use async in Rocket v0.5.
stevedonovan 4y ago
I suppose async web servers is the poster child of async, and drove a lot of the development. However, then _everything_ went async, adding the cognitive overhead of dealing with Rust async throughout the ecosystem, whether needed or not. In short, it still feels like a leaky abstraction: marvelous to look at working code, but errors (both compile and run-time) expose the underlying machinery underneath the syntactical sugar. This is probably heresy, but as a former Rust dev I'm enjoying web-services in Go more these days.
- afavour 4y ago
  I love Rust but I kind of agree. It’s really, really rare for a web service to need the low-level stuff Rust provides. A garbage collected is going to be just fine.
  - nbittich 4y ago
    I hated async for months. Refused to touch it. Recently I tried it again. It (seems) way better now. Just avoid weird libraries like diesel & rocket, and everything works just as expected. I even wrote some generic code with async and surprisingly it works without me having to get a phd in type theory to please the compiler.
  - marcosdumay 4y ago
    And if you want to make it async anyway, take a look at the abstractions a garbage collected language like Haskell can get you. (But well, the ones Go provide are probably more than enough already.) Rust was not made for web development, and the fact that people keep creating frameworks and keep deciding they are good only shows how bad the usual practices are around the web.
- deleted 4y ago
  [deleted]
- virtualritz 4y ago
  There are other applications, e.g. trading, where async is a godsent (monitoring hundreds of financial instrument for changes) but any sort of GC is prohibitive. And where you also need the fine grained control that Rust provides. E.g. halting all async tasks immediately while keeping a single core free to execute a trade as fast a possible.
cytzol 4y ago
I love Rouille: https://docs.rs/rouille/latest/rouille/ https://docs.rs/rouille/latest/rouille/
Waterluvian 4y ago
Is a thread per request scalable? Aren’t most of those threads just waiting for I/O? I guess thousands of concurrent requests via thousands of threads isn’t a big deal.
- marcosdumay 4y ago
  You mean at the application layer? There never was any problem scaling things at the application layer. You can use almost any architecture there without issues. All the bottlenecks are elsewhere.
- vbezhenar 4y ago
  It's reasonably scalable. Operating system can deal with thousands of sleeping threads just fine. And I don't need more than that (on a single machine anyway).
- aseipp 4y ago
  Yes, you can run absolutely massive systems with very high throughput and high concurrency using only OS threads and "normal" synchronous programming, if done correctly. However it's generally a pain in the ass because most languages often have their own threading models that may have their own limitations or interaction-with-the-OS quirks, while in C or C++ you're typically on your own for like, all your dependencies including trivialities like thread pools and stuff. And all newer languages tend to instead design their I/O ecosystems around asynchronous stuff. So you have to choose your poison. But handling massive systems always requires a bit of special care anyway. You will often encounter many other bottlenecks that hold your system back. There are other concerns like latency and utilization to care about. But assuming a purely "compute/IO" driven data plane, yes, you can scale synchronous APIs with threading quite far.
jokethrowaway 4y ago
async is pretty efficient, no reason to ditch that. It's just a pool of threads being used on demand. The source of "complexity" according to the author is in using traits to make sure the middlewares are defined correctly.

Is there popular Rust web server which uses just threads with no async stuff?

mfashby 4y ago

Rocket.rs I believe

DoubleFree 4y ago
Rocket is moving towards async as well
- 0x457 4y ago
  Rocket is not moving anywhere right now. 0.5 supposed to be async, but it's delayed more than a year because maintainer doesn't have time.
- Grimburger 4y ago
  You don't have to use async in Rocket v0.5.

stevedonovan 4y ago

I suppose async web servers is the poster child of async, and drove a lot of the development. However, then _everything_ went async, adding the cognitive overhead of dealing with Rust async throughout the ecosystem, whether needed or not. In short, it still feels like a leaky abstraction: marvelous to look at working code, but errors (both compile and run-time) expose the underlying machinery underneath the syntactical sugar. This is probably heresy, but as a former Rust dev I'm enjoying web-services in Go more these days.

afavour 4y ago
I love Rust but I kind of agree. It’s really, really rare for a web service to need the low-level stuff Rust provides. A garbage collected is going to be just fine.
- nbittich 4y ago
  I hated async for months. Refused to touch it. Recently I tried it again. It (seems) way better now. Just avoid weird libraries like diesel & rocket, and everything works just as expected. I even wrote some generic code with async and surprisingly it works without me having to get a phd in type theory to please the compiler.
- marcosdumay 4y ago
  And if you want to make it async anyway, take a look at the abstractions a garbage collected language like Haskell can get you. (But well, the ones Go provide are probably more than enough already.) Rust was not made for web development, and the fact that people keep creating frameworks and keep deciding they are good only shows how bad the usual practices are around the web.
deleted 4y ago
[deleted]
virtualritz 4y ago
There are other applications, e.g. trading, where async is a godsent (monitoring hundreds of financial instrument for changes) but any sort of GC is prohibitive. And where you also need the fine grained control that Rust provides. E.g. halting all async tasks immediately while keeping a single core free to execute a trade as fast a possible.

cytzol 4y ago

I love Rouille: https://docs.rs/rouille/latest/rouille/ https://docs.rs/rouille/latest/rouille/

Waterluvian 4y ago

Is a thread per request scalable? Aren’t most of those threads just waiting for I/O? I guess thousands of concurrent requests via thousands of threads isn’t a big deal.

marcosdumay 4y ago
You mean at the application layer? There never was any problem scaling things at the application layer. You can use almost any architecture there without issues. All the bottlenecks are elsewhere.
vbezhenar 4y ago
It's reasonably scalable. Operating system can deal with thousands of sleeping threads just fine. And I don't need more than that (on a single machine anyway).
aseipp 4y ago
Yes, you can run absolutely massive systems with very high throughput and high concurrency using only OS threads and "normal" synchronous programming, if done correctly. However it's generally a pain in the ass because most languages often have their own threading models that may have their own limitations or interaction-with-the-OS quirks, while in C or C++ you're typically on your own for like, all your dependencies including trivialities like thread pools and stuff. And all newer languages tend to instead design their I/O ecosystems around asynchronous stuff. So you have to choose your poison. But handling massive systems always requires a bit of special care anyway. You will often encounter many other bottlenecks that hold your system back. There are other concerns like latency and utilization to care about. But assuming a purely "compute/IO" driven data plane, yes, you can scale synchronous APIs with threading quite far.

jokethrowaway 4y ago

async is pretty efficient, no reason to ditch that. It's just a pool of threads being used on demand. The source of "complexity" according to the author is in using traits to make sure the middlewares are defined correctly.