I'm not familiar around the syntax, but I'm interested to know how much of this was a religious battle and how much of it results in meaningful complications for user code down the line. I've heard really good things about the Rust community (like nothing bad at all), until maybe two weeks ago when somebody mentioned this stuff. I'm a really big fan of not having religious battles.
Is this syntax for native coroutines? Can it be combined with existing user and stdlib syntax? What pathways for syntax development does this decision cut off entirely, and pathways does it leave open? What did the Rust community / maintainers learn from this debate, and how can the Rust community avoid such battles in the future?
> Due to the connotations of "religious battle", it's hard to get a good answer here. Nobody wants to be painted in this light.
Haven't we all found ourselves lined up as one of a pair of camps over some heated dispute over a bit of minutiae? The whole time you know it's a bit silly, but not entirely and you feel compelled to continue to argue.
Using a term like "religious battles" with tongue firmly in cheek is recognizing that we're prone to such things because we're human beings, by putting a lampshade on it.
This gets trickier when you have a community where some people practice religion in their daily life, and some people don't, and where the interactions between the two aren't always fun. It's not that the subject needs to be totally forbidden of course, but when it's just as easy to use different metaphors, we might as well.
@steveklabnik My apologies if I appeared to make light of the Rust community’s contributions. My definition of religious war is butting heads about problems that don’t have a clear right answer (tabs/spaces). If there are new things considered by the community that make the discussion worthwhile then it’s absolutely worth having; but if it causes people to burn out on the community down the line then maybe more moderation would be helpful. I have no experience leading anything like Rust, but I talked to contributors who burned out on Python and various libraries and it’s sad to see, so ideally Rust would forge a better path.
> My apologies if I appeared to make light of the Rust community’s contributions.
Not at all!
> My definition of religious war is butting heads about problems that don’t have a clear right answer (tabs/spaces).
So this is where we get into the meat of it. I personally do believe that a lot of the discussion was around things that don't have a clear right answer. But (and the post mentions this a bit), that doesn't mean that it's inherently religious, it means that different people value different aspects of the solution differently. The big difference between this discussion and the tabs/spaces discussion is that each person can make their own call with tabs and spaces, but this syntax affects every user of Rust. That means we can't just say "well this is a religious debate, do whatever" because then the feature does not exist.
> If there are new things considered by the community that make the discussion worthwhile then it’s absolutely worth having; but if it causes people to burn out on the community down the line then maybe more moderation would be helpful.
Yes, it is a fine line. There's a lot to it, but it is something that people are thinking about, for sure.
> I’m not sure whether the debate was taking all that into account
I can assure you that the overall development of the feature took every possible thing into account. Part of the reason that this was so synatx focused is that the team spent multiple years working on the semantics. The syntax was all that was left.
I am not 100% sure what you mean with the blog post link, as I'm not really a Python person, so I can't quite grok what you're talking about, exactly. If you can elaborate a bit I can too!
Maybe a better way I could phrase my concern would be whether the benefit to having the debate outweighs the cost, and what metrics Rust might keep track of that inform what the cost may be at every stage of the discussion.
The debate will always make sense for some time, but after a while it may block discussion of other features the Rust team might like to have for a roadmap milestone. Maybe having two forks with a tiny subset of async/await implemented (with something like tracer bullet development) would give stakeholders useful information on what the implementation cost would look like, what testing coverage overhead would be, and other metrics that balance the theoretical with the practical.
As to the statement that async/await was a smaller part of grokking concurrency in a language, maybe a better blog post might be this one:
Some helpful background: Python has the notion of a global interpreter lock (GIL), which prevents concurrent CPU-bound tasks in threads from being effectively parallelized in Python. As a result, most development of concurrent tasks are I/O-bound, or call some C/Fortran library where the GIL does not block CPU-bound tasks, or use a process pool. I don't think this should affect the discussion because I think the issues with concurrency he talks about don't care about what resource it's bound by, they may just be more evident with I/O-bound tasks or provide greater perspective.
So `njs` (a Python core developer) went and developed an async I/O library called `trio`, which has the concept of "nurseries", which is a container for dynamic tasks. Nursery exit will block on the dynamic tasks within exiting, in order to make sure that the concurrent tasks within can appear as a single black box to the outside world. I believe he was saying how the async/await feature in Python should be combined with other control flow primitives, because otherwise creating tasks that outlive the parent, error propagation, and resource cleanup may result in spaghetti behavior and spaghetti code. He also claims that clean control flow also results in new features that assume said control flow, which makes development more powerful. This goes back to my assertion that async/await isn't the end-all/be-all in terms of making concurrent code grokkable.
One quote from that blog post that mentions Rust and thread correctness (I'm not sure if it's outdated):
"""
Go statements break error handling. Like we discussed above, modern languages provide powerful tools like exceptions to help us make sure that errors are detected and propagated to the right place. But these tools depend on having a reliable concept of "the current code's caller". As soon as you spawn a task or register a callback, that concept is broken. As a result, every mainstream concurrency framework I know of simply gives up. If an error occurs in a background task, and you don't handle it manually, then the runtime just... drops it on the floor and crosses its fingers that it wasn't too important. If you're lucky it might print something on the console. (The only other software I've used that thinks "print something and keep going" is a good error handling strategy is grotty old Fortran libraries, but here we are.) Even Rust – the language voted Most Obsessed With Threading Correctness by its high school class – is guilty of this. If a background thread panics, Rust discards the error and hopes for the best.
"""
> My impression of async/await is that it’s one part of making concurrency grokkable, and I’m not sure whether the debate was taking all that into account
That's a different question than "where does the await go" and it was certainly taken into account.
Is this syntax for native coroutines? Can it be combined with existing user and stdlib syntax? What pathways for syntax development does this decision cut off entirely, and pathways does it leave open? What did the Rust community / maintainers learn from this debate, and how can the Rust community avoid such battles in the future?