Hacker News Reader

Comment by jstrong | Hacker News Reader

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.

View on HN

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).

I mean, you can always just use an async crate and use async_std::task::block_on.

Only if no other crate in your executable uses tokio or another executor, right?

Mixing executors is approximately fatal, AFAICT.

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.

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!".

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

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.

You can avoid async ecosystem with mio_httpc for http client. tiny_http for http server. Both work well.

Try https://github.com/algesten/ureq, it’s very nice and not async.

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

(Maybe this uses async rust under the hood, but you don't have to care about it)

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.

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!

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

Mmmyeah, they said this about python too...

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.

>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.

Reply on news.ycombinator.com