9 ms·

I've been primarily coding in rust since 2018. I never cared for async/await, and I've never used it. (at some point, coding event loops became very natural/com

I've been primarily coding in rust since 2018. I never cared for async/await, and I've never used it. (at some point, coding event loops became very natural/comfortable for me, and I have no trouble writing "manual" epoll code with mio/mio_httpc). one nice thing about rust's async/await is, you don't have to use it, and if you don't, you don't pay for it in any way. sure, I run into crates that expect me to bring in a giant runtime to make a http request or two (e.g. rusoto), but for the most part I have not had any issues productively using sans-async rust during the last few years. so, if you don't like async/await, just don't use it! it doesn't change anything about the rest of rust.

theopsguy 6y ago
+1000 in this. You can just use rust like c/c++ if you don’t want to buy into async.
boulos 6y ago
Maybe it’s just the hyper and related crates universe, but my perception (see my sibling comment) is that more and more of the ecosystem will be “async only”. Like you, I think that’s sort of fine, because you can always roll your own. But it’s also kind of sad: one of the best things about the Rust ecosystem is that you can so effortlessly use a small crate in a way you really can’t in C++ (historically, maybe modules will finally improve this).
- lalaithion 6y ago
  I mean, you can always just use an async crate and use async_std::task::block_on.
  - boulos 6y ago
    Only if no other crate in your executable uses tokio or another executor, right? Mixing executors is approximately fatal, AFAICT.
    - cjg 6y ago
      I think that's too strong. You could have two executors with no problem. What might cause issues is if code running on one executor needed close interaction with the other - such as running a task on the other executor. Most of the time this is just avoided by using only one executor. But that's not the only way.
      - boulos 6y ago
        That's a good clarification. What matters is if tasks "running on" one executor end up spawning / blocking on a task "on another executor". You can definitely have "side by side, who cares". The danger though is that you're just using some library, and if it suddenly assumes it can do tokio::task::block_in_place but you were using some other executor you get "Hey! No runtime!".
omginternets 6y ago
Mmmyeah, they said this about python too...
- jstrong 6y ago
  rust has avoided many pitfalls that python fell into. one example is the way that rust 2015 edition code works seamlessly with rust 2018 edition code, unlike the python2 -> python3 debacle. another is cargo vs pip/poetry/this month's python package manager. so, using python as an example isn't very convincing to me.
  - omginternets 6y ago
    >so, using python as an example isn't very convincing to me. That's because you're focusing on precisely the points where Rust has done better than Python, and conspicuously glossing over Python's asyncio debacle ... which looks exactly like Rust's. In a nutshell, it works like this: 1. New syntax is introduced 2. We are told it's optional 3. The ecosystem adopts it, and it be comes de facto required So right back at ya -- I am not convinced in the least by Rust's argumentation ;) It's unclear to me how leadership can fix this. The cat is out of the bag, and the language must now contend with a second-order embedded syntax. Avoiding this becomes increasingly difficult as it is adopted in the ecosystem; just ask the C++ guys how they feel about exceptions.
ntr-- 6y ago
I don't know how anybody can say this with a straight face. Even in a systems context I think it's pretty reasonable to want to either perform or receive a HTTP request, as soon as you do that in Rust you are funneled into Hyper or something built on top of it (like reqwest) and instantly are dependent on tokio/mio. The very first example in the reqwest readme^1 has tokio attributes, async functions AND trait objects. It's impossible that a beginner attempting to use the language to do anything related to networking won't be guided into the async nightmare before they have even come to grips with the borrow checker. 1. https://crates.io/crates/reqwest https://crates.io/crates/reqwest
- iso8859-1 6y ago
  jstrong didn't mention anything about beginners or how a typical user is nudged. It's just a description of how they work. They even pointed out which HTTP library they use. There is nothing in their post that requires a curved face.
- rapsey 6y ago
  You can avoid async ecosystem with mio_httpc for http client. tiny_http for http server. Both work well.
- thijsc 6y ago
  Try https://github.com/algesten/ureq https://github.com/algesten/ureq, it’s very nice and not async.
- ogoffart 6y ago
  Reqwest lets you choose between async or not. It has a "blocking" module with a similar API, but no async functions. https://docs.rs/reqwest/0.11.2/reqwest/blocking/index.html https://docs.rs/reqwest/0.11.2/reqwest/blocking/index.html (Maybe this uses async rust under the hood, but you don't have to care about it)
  - iso8859-1 6y ago
    It is not a question of whether something is blocking or not, blocking is easy. It is a question of whether you can have asynchronicity without await/async. And you can, using mio, as jstrong suggested. You'll manually poll the event loop.
joseluisq 6y ago
+2 Yes! Using `sans-async` must NOT diminish our productivity in comparison with `async` counterpart. > at some point, coding event loops became very natural/comfortable for me In fact it is, I'm very happy with it too. > one nice thing about rust's async/await is, you don't have to use it, and if you don't, you don't pay for it in any way. You've said it!

theopsguy 6y ago

+1000 in this. You can just use rust like c/c++ if you don’t want to buy into async.

boulos 6y ago

Maybe it’s just the hyper and related crates universe, but my perception (see my sibling comment) is that more and more of the ecosystem will be “async only”. Like you, I think that’s sort of fine, because you can always roll your own. But it’s also kind of sad: one of the best things about the Rust ecosystem is that you can so effortlessly use a small crate in a way you really can’t in C++ (historically, maybe modules will finally improve this).

lalaithion 6y ago
I mean, you can always just use an async crate and use async_std::task::block_on.
- boulos 6y ago
  Only if no other crate in your executable uses tokio or another executor, right? Mixing executors is approximately fatal, AFAICT.
  - cjg 6y ago
    I think that's too strong. You could have two executors with no problem. What might cause issues is if code running on one executor needed close interaction with the other - such as running a task on the other executor. Most of the time this is just avoided by using only one executor. But that's not the only way.
    - boulos 6y ago
      That's a good clarification. What matters is if tasks "running on" one executor end up spawning / blocking on a task "on another executor". You can definitely have "side by side, who cares". The danger though is that you're just using some library, and if it suddenly assumes it can do tokio::task::block_in_place but you were using some other executor you get "Hey! No runtime!".

omginternets 6y ago

Mmmyeah, they said this about python too...

jstrong 6y ago
rust has avoided many pitfalls that python fell into. one example is the way that rust 2015 edition code works seamlessly with rust 2018 edition code, unlike the python2 -> python3 debacle. another is cargo vs pip/poetry/this month's python package manager. so, using python as an example isn't very convincing to me.
- omginternets 6y ago
  >so, using python as an example isn't very convincing to me. That's because you're focusing on precisely the points where Rust has done better than Python, and conspicuously glossing over Python's asyncio debacle ... which looks exactly like Rust's. In a nutshell, it works like this: 1. New syntax is introduced 2. We are told it's optional 3. The ecosystem adopts it, and it be comes de facto required So right back at ya -- I am not convinced in the least by Rust's argumentation ;) It's unclear to me how leadership can fix this. The cat is out of the bag, and the language must now contend with a second-order embedded syntax. Avoiding this becomes increasingly difficult as it is adopted in the ecosystem; just ask the C++ guys how they feel about exceptions.

ntr-- 6y ago

I don't know how anybody can say this with a straight face. Even in a systems context I think it's pretty reasonable to want to either perform or receive a HTTP request, as soon as you do that in Rust you are funneled into Hyper or something built on top of it (like reqwest) and instantly are dependent on tokio/mio. The very first example in the reqwest readme^1 has tokio attributes, async functions AND trait objects. It's impossible that a beginner attempting to use the language to do anything related to networking won't be guided into the async nightmare before they have even come to grips with the borrow checker. 1. https://crates.io/crates/reqwest https://crates.io/crates/reqwest

iso8859-1 6y ago
jstrong didn't mention anything about beginners or how a typical user is nudged. It's just a description of how they work. They even pointed out which HTTP library they use. There is nothing in their post that requires a curved face.
rapsey 6y ago
You can avoid async ecosystem with mio_httpc for http client. tiny_http for http server. Both work well.
thijsc 6y ago
Try https://github.com/algesten/ureq https://github.com/algesten/ureq, it’s very nice and not async.
ogoffart 6y ago
Reqwest lets you choose between async or not. It has a "blocking" module with a similar API, but no async functions. https://docs.rs/reqwest/0.11.2/reqwest/blocking/index.html https://docs.rs/reqwest/0.11.2/reqwest/blocking/index.html (Maybe this uses async rust under the hood, but you don't have to care about it)
- iso8859-1 6y ago
  It is not a question of whether something is blocking or not, blocking is easy. It is a question of whether you can have asynchronicity without await/async. And you can, using mio, as jstrong suggested. You'll manually poll the event loop.

joseluisq 6y ago

+2 Yes! Using `sans-async` must NOT diminish our productivity in comparison with `async` counterpart. > at some point, coding event loops became very natural/comfortable for me In fact it is, I'm very happy with it too. > one nice thing about rust's async/await is, you don't have to use it, and if you don't, you don't pay for it in any way. You've said it!