Why asynchronous Rust doesn't work • Hacker News Board

Re: Why asynchronous Rust doesn't work

#371

Post by adamch » Wed, Mar 10, 2021, 3:51 PM UTC

__s wrote: post #317

adamch wrote: post #132

This is pretty overblown. I write async rust every day for my job, just fine, with no real problems. Probably because I'm consuming other libraries, I'm not trying to write my own. I use well-tested libraries like Actix-Web or occasionally Tokio. I've migrated multiple projects from futures to async/await once the syntax came out. ' The problems the author is describing might apply more to library authors, but for th…

Agreed, I rewrote a 10k line a js websocket based game server[0] a few months ago into async Rust. It was mostly painless I didn't have to deal with closures much because I'm comfortable writing a 2000 line match 0: https://github.com/serprex/openEtG/tree/master/src/rs/server

Wow, awesome code. I really respect the 2000 line match, it's a really neat abstraction. Keep some state, have an exhaustive list of everything users can do, and define exactly how each possible user action can change that state. Beautiful.

Re: Why asynchronous Rust doesn't work

#372

Post by anp » Wed, Mar 10, 2021, 3:53 PM UTC

newpavlov wrote: post #264

ben0x539 wrote: post #211

Earlier quoted context omitted.

What happens if you drop the task between 1 and 2? Does dropping block until the cancellation of both tasks is complete?

As I've mentioned several times, in this model you can not simply "drop the task" without running its asynchronous Drop. Each state in FSM will be generated with a "drop" transition function, which may include asynchronous cancellation requests (i.e. cleanup can be bigger than one transition function and may represent a mini sub-FSM). This would require introducing more fundamental changes to the language (same as wi…

“Rust would have been a better language by breaking its stability guarantees” is just saying “Rust would have been a better language by not being Rust.” Maybe true, but not relevant to the people whose work you’ve blanket criticized. Rust language designers have to work within the existing language and your arguments are in bad faith if you say “async could have been perfect with all this hindsight and a few breaking language changes”.

Re: Why asynchronous Rust doesn't work

#373

Post by anp » Wed, Mar 10, 2021, 3:56 PM UTC

steveklabnik wrote: post #351

eru wrote: post #64

Earlier quoted context omitted.

Interesting! For comparison, Haskell went with the library approach but has the syntactic sugar of the equivalent of `and_then` built into the language. (I am talking about Monads and do-notation.) It's a bit like iterating in Python: for-loops are a convenient syntactic sugar to something that can be provided by a library.

It is a little old, but for the general gist of it, http://aturon.github.io/tech/2018/04/24/async-borrowing/ is an amazing description of the problem here. It is a PhD level research problem to know if monads and do notation would be able to work in Rust. The people who are most qualified to look into it (incidentally: a lot of the same crew was who was working on async) believe that it may literally be impossible.

My impression is that some of them even burnt out in slog of a supposedly rushed process to land async/await!

Re: Why asynchronous Rust doesn't work

#374

Post by artursapek » Wed, Mar 10, 2021, 3:58 PM UTC

newpavlov wrote: post #169

jzoch wrote: post #163

Earlier quoted context omitted.

I and many others would disagree that they made the decision "at the expense of the long-term Rust health". You aren't arguing in good faith if you put words in their mouth. There is no data to suggest the long-term health of rust is at stake because of the years long path they took in stabilizing async today. There are merits to both models but nothing is as clear-cut as you make it to be - completion-based futures…

I do not put words in their mouth or have you missed the "in my opinion" part? The issues with Pin, problems around noalias, inability to design a proper async Drop solution, not a great compatibility with io-uring and IOCP. In my eyes they are indicators that Rust health in the async field has suffered. >Completion based is totally better and the only reason it wasn't done was because it would take too long and Rust…

Isn't it very likely that going the other route would also result in a different but equally long list of issues?

Re: Why asynchronous Rust doesn't work

#375

Post by devpbrilius » Wed, Mar 10, 2021, 4:00 PM UTC

A main developer on site with paid job is necessarily its consumer, not exact producer.

Re: Why asynchronous Rust doesn't work

#376

Post by xiphias2 » Wed, Mar 10, 2021, 4:00 PM UTC

thu2111 wrote: post #223

xiphias2 wrote: post #36

Earlier quoted context omitted.

That’s why it’s amazing, type safe efficient multi-threading without dynamic memory allocation with a nice syntax...it’s the holy grail of server programming.

Why would I want to write a server in a language that requires such awkward approaches to basics like coroutines and dynamic dispatch when I could use kotlin on the JVM and get pauseless GC, ultra fast edit/compile/run cycles, efficient and powerful coroutines, and eventually Loom which will eliminate the whole problem of coloured functions completely and let me just forget about coroutines? Multi threading bugs are…

Good luck getting Google's ad backend with 20ms latency budget and billions of dollars of revenue approved with the JVM.

Therr are many tasks where what you suggests is just too slow and unpredictable.

Don't get me wrong, I think JVM is great, it's just not systems level programming.

Re: Why asynchronous Rust doesn't work

#377

Post by steveklabnik » Wed, Mar 10, 2021, 4:05 PM UTC

newpavlov wrote: post #370

steveklabnik wrote: post #348

Earlier quoted context omitted.

> Please, tone down your replies. You cannot literally make extremely inflammatory comments about people's work, and accuse them of all sorts of things, and then get upset when they are mad about it. You've made a bunch of very serious accusations on multiple people's hard work, with no evidence, and with arguments that are shaky at best, on one of the largest and most influential forums in the world. I mean, you can…

I am not mad, it was nothing more than an attempt to urge a more civil tone from boats. If you both think that such tone is warranted, then so be it. But it does affect my (really high) opinion about you. I do understand the pain of your dear work to be harshly criticized. I have experienced it many times in my career. But my critique intended as a tough love for the language in which I am heavily invested in. If you…

I do not doubt that you care about Rust. Civility, though, is a two-way street. Just because you phrase something in a way that has a more neutral tone does not mean that the underlying meaning cannot be inflammatory.

"Instead of carefully weighing advantages and disadvantages of both models," may be written in a way that more people would call "civil," but is in practice a direct attack on both the work, and the people doing the work. It is extremely difficult to not take this as a slightly more politely worded "fuck you," if I'm being honest. In some sense, that it is phrased as being neutral and "civil" makes it more inflammatory.

You can have whatever opinion that you want, of course. But you should understand that the stuff you've said here is exactly that. It may be politely worded, but is ultimately an extremely public direct attack.

Re: Why asynchronous Rust doesn't work

#378

Post by mst » Wed, Mar 10, 2021, 4:06 PM UTC

steveklabnik wrote: post #348

newpavlov wrote: post #312

Earlier quoted context omitted.

Thank you for the link! But immideately we can see the false equivalence: completion based API does not imply the callback-based approach. The article critigues the latter, but not the former. Earlier in this thread I've described how I see a completion-based model built on top of FSMs generated by compiler from async fns. In other words, the arguments presented in that article do not apply to this discussion. >The p…

> Please, tone down your replies. You cannot literally make extremely inflammatory comments about people's work, and accuse them of all sorts of things, and then get upset when they are mad about it. You've made a bunch of very serious accusations on multiple people's hard work, with no evidence, and with arguments that are shaky at best, on one of the largest and most influential forums in the world. I mean, you can…

I found it highly critical but not inflammatory - though I'm not sure if I'd've felt the same way had they been being similarly critical of -my- code.

However, either way, responding with condescension (which is how the 'industry standard' thing came across) and outright aggression is never going to be constructive, and if that's the only response one is able to formulate then it's time to either wait a couple hours or ask somebody else to answer on your behalf instead (I have a number of people who are kind enough to do that for me when my reaction is sufficiently exothermic to make posting a really bad idea).

boats-of-a-year ago handled a similar situation much more graciously here - https://news.ycombinator.com/item?id=22464629 - so it's entirely possibly a lockdown fatigue issue - but responding to calmly phrased criticism with outright aggression is still pretty much never a net win and defending that behaviour seems contrary to the tone the rust team normally tries to set for discussions.

Re: Why asynchronous Rust doesn't work

#379

Post by ruph123 » Wed, Mar 10, 2021, 4:10 PM UTC

lutoma wrote: post #240

noncoml wrote: post #39

> And, as I said at the start, that makes me kinda sad, because I do actually like Rust. I think that’s the most important part of the article. People like Rust but it’s becoming more complex than C++. But unlike C++ it’s more difficult to pick and choose what you use. Rust’s death will be one by thousand cuts. “I really like the language but can’t justify all that complexity in my new small and simpke project” is wh…

As a C developer who has never really used C++ or Rust I sort of agree. Looking at Rust introductory guides I increasingly get the same feeling as looking at C++ things, where there's just _too much_ of everything. I know it's a subjective feeling that is probably unfair to the language, but it's still the impression I get. I'm confident if I actually put in the work to learn Rust I would end up liking it and I plan…

> As a C developer who has never really used C++ or Rust I sort of agree.

So you are saying:

“As someone who has never really used A or B I agree with the comparison of A and B.”

Pretty much sums up some of the comments here. People who don’t spent much (or any) time with Rust make (or support) wild statements like this.

Rust is what you can learn in a few weeks, C++ takes a lifetime and then you are dead.

Re: Why asynchronous Rust doesn't work

#380

Post by iso8859-1 » Wed, Mar 10, 2021, 4:13 PM UTC

ogoffart wrote: post #197

ntr-- wrote: post #129

Earlier quoted context omitted.

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…

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.