3 ms·
Rust's async model takes very little time to grasp. It's very explicit. Nothing runs in the background (contrast that with NodeJS). You have strong static types
by pas 6y ago
Rust's async model takes very little time to grasp. It's very explicit. Nothing runs in the background (contrast that with NodeJS). You have strong static types to help you to know when you got a Future, you can decide where/when to await it.
It's programming with threads, where you have a thread pool and pipes to put tasks onto that and a helper function/macro. Await does this under the hood of course.
- baby 6y agoThat is until you get a weird error or try to do something more complicated.
- pas 6y agoThis is perfectly valid for NodeJS, Python (async and/or threads, hello GIL[0]), and a host of other languages/runtimes. Also I agree that multi-threaded Rust is probably the best alternative to async Rust. [0] I have no problems with the GIL, but it's yet another factor to consider when a python multi-threaded program stops working as intended
- EugeneOZ 6y agoNot sure how you can compare then. You can’t do with the threads what you can do with async functions.
- pas 6y ago? You can do exactly the same thing, after all async is just a big auto-generated state-machine that puts jobs onto a thread pool and waits for them. Nginx is hand crafted (artisanal!) event-driven C, which is exactly how async runtimes also work. A big loop (the event loop, usually an infinite `while` blocked on epoll()). For example NodeJS uses libuv for this. The big advantage of first class async support is that we don't have to do this by hand. Plus it makes some optimizations easier (eg. putting things on the stack instead of assigning each event handler a slice of some global [heap allocated] structure). Or maybe I'm simply misunderstanding what you meant. In that case cloud you clarify please?