undefined

points

[-]

Some of the burnout no doubt being due to the catastrophizing of every decision by the community and the extreme rhetoric used across the board.

Great to see people wanting to get involved with the project, though. That’s the beauty of open source: if it aggravates you, you can fix it.

by selfhoster13122 hours ago|

parent|

[-]

As an example of this, i remember a huge debate at the time about `await foo()` vs `foo().await` syntax. The community was really divided on that one, and there was a lot of drama because that's the kind of design decision you can't really walk back from.

Retrospectively, i think everyone is satisfied with the adopted syntax.

by zozbot2341 hours ago|

parent|

[-]

It makes sense that there was a huge debate, because the postfix .await keyword was both novel (no other languages had done it that way before) and arguably the right call. Of course, one can argue that the ? operator set a relevant precedent.

by jurgenburgen1 hours ago|

parent|

prev|

[-]

> Retrospectively, i think everyone is satisfied with the adopted syntax.

Maybe it’s a case of agree and commit, since it can’t really be walked back.

by diondokter1 hours ago|

parent|

[-]

Various prominent people have said years after that .await was the correct choice after all

by nixpulvis1 hours ago|

prev|

[-]

I think it's partially accurate, and partially a consequence of how async fractures the design space, so it will always feel like a somewhat separate thing, or at least until we figure out how to make APIs agnostic to async-ness.

by meowface1 hours ago|

parent|

[-]

I am a beginner to Rust but I've coded with gevent in Python for many years and later moved to Go. Goroutines and gevent greenlets work seamlessly with synchronous code, with no headache. I know there've been tons of blog posts and such saying they're actually far inferior and riskier but I've really never had any issues with them. I am not sure why more languages don't go with a green thread-like approach.

by dminik1 hours ago|

parent|

[-]

Because they have their own drawbacks. To make them really useful, you need a resizable stack. Something that's a no-go for a runtime-less language like Rust.

You may also need to setup a large stack frame for each C FFI call.

by jolux1 hours ago|

parent|

prev|

[-]

Rust originally came with a green thread library as part of its primary concurrency story but it was removed pre-1.0 because it imposed unacceptable constraints on code that didn’t use it (it’s very much not a zero cost abstraction).

As an Elixir + Erlang developer I agree it’s a great programming model for many applications, it just wasn’t right for the Rust stdlib.

by nixpulvis1 hours ago|

parent|

prev|

[-]

One of Rust's central design goals is to allow zero cost abstractions. Unifying the async model by basically treating all code as being possibly async would make that very challenging, if not impossible. Could be an interesting idea, but not currently tenable.

One problem I have with systems like gevent is that it can make it much harder to look at some code and figure out what execution model it's going to run with. Early Rust actually did have a N:M threading model as part of its runtime, but it was dropped.

I think one thing Rust could do to make async feel less like an MVP is to ship a default executor, much like it has a default allocator.