Avoid Async Rust - blog.hugpoint.tech (blog.hugpoint.tech)
from lysdexic@programming.dev to rust@programming.dev on 23 Jan 2024 15:13
https://programming.dev/post/8996884

#rust

threaded - newest

d_k_bo@feddit.de on 23 Jan 2024 16:08 next collapse

insert “STOP USING $X” meme here

kevincox@lemmy.ml on 23 Jan 2024 18:05 next collapse

Async Rust is objectively bad language feature

That is all I need to read to know that this isn’t a well-reasoned complaint.

async Rust definitely isn’t perfect, and there is definitely room for critique. But it is very clearly not objectively bad.

crispy_kilt@feddit.de on 23 Jan 2024 19:08 next collapse

No. I like it.

huntrss@feddit.de on 23 Jan 2024 20:12 collapse

I think the article is ok, and yes I read it ;)

I think the title is unnecessary click-baity, because there are some relevant truths to it.

Most relevant truth us, that a lot of applications won’t need async since they are not large enough, not IO bound etc…

I think one of the misconceptions in this article is, that the author arguments that you need to be an Amazon or google to benefit from async. This is not completely wrong but, as a software developer in the embedded system industry that I am, I must say it is also very relevant for embedded systems.

If someone read the article and is unsure about async, I can recommend these two articles that provide insights “from the other side” these means devs that actually find async relevant and beneficial:

notgull.net/why-you-want-async/

without.boats/blog/why-async-rust/ The article from boats is absolutely worth it. Even if you are an async sceptic.

Finally regarding the introduction of async APIs and abstractions into any code base:

Creating an async application or sync application is an architectural decision. And since architecture is the sum of all decisions that are hard to change (I think this is from Martin Fowler) thus decision - async or sync - is hard to change and one must live with it.

Yes, there are languages like Go or Erlang that resolve this async vs. sync problem, they come at a cost (having a runtime, at least Go has one afaik, I no nothing about Erlang). And choosing a particular language is also an architectural decision and hence hard to change.

taladar@sh.itjust.works on 24 Jan 2024 09:25 next collapse

Creating an async application or sync application is an architectural decision. And since architecture is the sum of all decisions that are hard to change (I think this is from Martin Fowler) thus decision - async or sync - is hard to change and one must live with it.

For applications that is true but for libraries it often is not. You can e.g. design REST API libraries quite well with most of the code ignoring sync vs. async completely and only the part that actually performs requests in a general way has to handle the distinction which is why many of them include both versions.

huntrss@feddit.de on 24 Jan 2024 13:11 collapse

Thanks for the clarification. This is especially true for libraries that can benefit from async.

soulsource@discuss.tchncs.de on 24 Jan 2024 15:26 collapse

There is also the y-combinator thread that discusses async as implemented in Rust compared to using Monads to represent async computations: news.ycombinator.com/item?id=17536441

The arguments that withoutboats presented in that thread convinced me that Rust’s async is the better of these alternatives for a language like Rust.

Another thing that helped to convince me of that is that I tried playing around with Free Monads and the Writer and State Monad in Rust, and found them to be very un-ergonomic. Rust is very explicit about heap allocations, and when using basically any Monad that’s more complex than Option/Result I found myself typing Rc::new() way more often than I would have liked… If you add do-notation to the mix, things get even more verbose (aka: annoying): github.com/bodil/higher/issues/6

So, yeah. Rust async isn’t perfect, but it’s probably better to have it than not.