Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A four year plan for async Rust

without.boats

Post reply on HN
Print view View original

31–40 of 236 posts

Re: A four year plan for async Rust

#31

Post by the__alchemist »

withoutboats3 wrote: post #22
the__alchemist wrote: post #19

Earlier quoted context omitted.

> the kind of ... service that benefits from using non-blocking IO. Async, in the sense from the article, and non-blocking aren't synonyms. Not using Async doesn't imply blocking.

What Rust libraries use non-blocking IO without using async syntax? I don't know of any. This interpretation of the request is new to me: I've exclusively heard complaints about libraries using async from people who want to use blocking IO. (Also, in case it isn't obvious: I wrote the article in question.)

I usually do non-blocking ops with hardware interrupts, DMA, distributed computing (over CAN etc), and multiple cores. For GPOS/Desktop PCs, threads, SIMD (GPU or CPU etc) are effective.

More generally than the concurrency operations I described, are any sort of event-loop or state machine, of which Async is one example.

Re: A four year plan for async Rust

#32

Post by Sprocklem »

andrewstuart wrote: post #14

I thought async and await were kind of logical builds on top of generators but this is saying rust has no generators. That’s how it works in javascript and as a commenter mentions in Python too, right?

They are in some languages, but Rust instead implemented them with a pollable Future trait. The async keyword, then, causes the block to desugar into a new type that implements Future. In order to emulate a coroutine, the generated poll function includes a state machine that tracks the await point where the function was suspended.

Re: A four year plan for async Rust

#33

Post by CyberDildonics »

echelon wrote: post #17
seanw444 wrote: post #10

Earlier quoted context omitted.

The point can be made equally well without the elitist condescension.

It's not elitist. I'm sick of people perpetuating this about the Rust ecosystem. It's not a month that goes by that there isn't some article badmouthing the language and its features. Stop it. We want our language to gain support in enterprise so we can get paid to write it as our day job. These articles and negative comments are not helping.

Your comments boil down to "I think rust is easy, stop giving your opinions that don't agree".

You didn't make any arguments here at all. You can check my other comment for detailed reasons why async in a language is not a good approach to concurrency. The overview is that is just isn't a holistic solution and the only time it will solve someone's problem is if they have extremely simple concurrency needs in the first place and those never scale or change.

Re: A four year plan for async Rust

#34

Post by orcy »

inamberclad wrote: post #2

Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

I am in doubts about async too. For better understanding I have implemented my own executor and io library (even with some tricky async destruction) and I am not quite happy with it. The problem is that in rust there are no other good methods to write safe async code, are there? My impression that borrow checker forbids lots of patterns I know from other language.

Re: A four year plan for async Rust

#35

Post by FencePost12 »

echelon wrote: post #17
seanw444 wrote: post #10

Earlier quoted context omitted.

The point can be made equally well without the elitist condescension.

It's not elitist. I'm sick of people perpetuating this about the Rust ecosystem. It's not a month that goes by that there isn't some article badmouthing the language and its features. Stop it. We want our language to gain support in enterprise so we can get paid to write it as our day job. These articles and negative comments are not helping.

Choosing a technology because it’s what you want to work in is never proper engineering for non-college projects. Choose the best technology to…you know…create a quality product for your customer. You can get paid that way too.

Re: A four year plan for async Rust

#36

Post by withoutboats3 »

couchand wrote: post #16
withoutboats3 wrote: post #13

Earlier quoted context omitted.

What Rust libraries use async that you think should not? I can think of one, but otherwise every library I've encountered uses async because its intended for the kind of networking service that benefits from using non-blocking IO.

Just because it's a network request doesn't mean it benefits from using async. EDIT: to add a specific example, postgres. I understand from sfackler's perspective why it makes sense to maintain just an async library and a sync wrapper around it. But from the user's perspective there'a absolutely no reason that all of tokio should be required to talk to their db.

As a user who has maintained network services that communicate with Postgres, I'm very glad that sfackler's postgres library doesn't perform blocking IO calls, as that would make it unfit for purpose for me.

Re: A four year plan for async Rust

#37

Post by dgacmu »

the__alchemist wrote: post #3
inamberclad wrote: post #2

Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

I'm with you. I feel like an outcast in the Rust OSS embedded circles when I bring this up. They are heavily into async/embassy.

I'm curious why you don't like it for embedded - embassy has been an absolute delight for me thus far, and my primary complaint about it is just that it doesn't have the breadth of hardware support (yet?). It's been the thing that has redeemed Rust async for me, as otherwise, I tend to find the tension the author notes frustrating as well.

Re: A four year plan for async Rust

#38

Post by Verdex »

lucasyvas wrote: post #20
inamberclad wrote: post #2

Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

This is consistent with the author's assessment - the incomplete implementation of async makes it very challenging to advocate for, despite the fact that it was the only logical choice given Rust's design goals. I will say that the notion that you must make your whole project async is largely true (except that you can block on futures with all runtimes), but this is more symptomatic of the fact that Rust has hitched…

> It's equally desired at "web server and above" and "operating system and below", which probably makes it one of the hardest languages on the planet to design.

My theory as to why C++ has become as a problematic language as it has is because it is able to do it all. And "all" doesn't fit nicely into a single package or paradigm.

I don't like async (in any language), so your post immediately piqued my interest. I'm not that interested in 'webserver and above' so of course that would be where people find async useful.

It is possible that there is no way to unify these two domains into a single language (at least without becoming c++). Although, then again, it might be that if you think about it long enough then the unification mechanism becomes apparent.

Re: A four year plan for async Rust

#39

Post by withoutboats3 »

dymk wrote: post #24
echelon wrote: post #17

Earlier quoted context omitted.

It's not elitist. I'm sick of people perpetuating this about the Rust ecosystem. It's not a month that goes by that there isn't some article badmouthing the language and its features. Stop it. We want our language to gain support in enterprise so we can get paid to write it as our day job. These articles and negative comments are not helping.

This article is by a Rust contributor. I'm sure they want to see Rust be more widely adopted as well. Async is pretty great, but it's not perfect, and in some situations its shortcomings cannot be worked around easily.

I think the comment this person was responding to is completely off topic for my blog post, and extremely shallow. I share the person you're responding to's frustration with how async Rust is talked about on Hacker News.

Re: A four year plan for async Rust

#40

Post by lucasyvas »

I think std needs a default runtime, and we might as well make it tokio, but maybe make the single-threaded executor the default instead and tweak the API where appropriate to align with this change.

Swapping the executors out should absolutely be a feature, and the traits should be portable, but a way to start fixing the situation beyond the great suggestions in this proposal is to acknowledge that std and no-std users are different, and std users are often developing applications and prefer sane defaults.

Post reply on HN