Apple is on Holiday shutdown. Please be polite, and realize that they are not being paid to provide instant replies to forum posts.
9 Likes
And as already said, async/await requires other features that have to be implemented first (like ownership manifesto).
And even with that, there is a lot of discussion to have (concurrency model, actors, …) before working on async/await which is just a syntactic sugar above what will be designed first.
Callback is pretty messy in Asynchronous.
I guess Callback Chris Lattner will do the job... eh?
is this the only place where concurrency topics are discussed? IIRC the kickoff for async/await, etc discussions was in 2017 and now is almost 2020, and it doesn't look heavily discussed here (unless there is a secret channel of course) and languages like kotlin that started later already have it but not us, and languages that started earlier can give us some great kickstarter ideas so we don't have to do everything from scratch?
until it is in the language, can anyone explain me in one or few lines from a bird view perspective, and from a user point of view -- what will be the massive benefits of this language feature compared to using one of the libraries in the wild that claim to provide coroutines / async/await today (i will not name them but there are a few). is that the quantity aspect, for example with those libraries i can create, say 100K coroutines while with the language ones I can have 1M or what?
1 Like
I tend to agree with some of this. It may just be a lack of effort on my part, but I find that I have no idea about what is planned/being implemented. Sure, there are manifestos and sometimes a person pops up saying that the core team is currently focused on the ownership model, but that’s about it. Is there a way to find the current state of these efforts? The development of Swift is largely guided (controlled even) by the core team, but we have little insight into what is actually happening. It is quite frustrating to be left in the dark like this. Or am I missing something? Is there a page similar to the evolution proposal status for more long-term goals?
2 Likes
True but that requires the core team to focus some mental energy and effort into keeping us updated. I've been wondering if there's a niche opportunity for someone interested in journalism and technology to just be able to poke their mind and release weekly or even monthly news/interviews. It's a way for that person to gain visibility if they're able to make quality content and for the team to be able to keep us updated without expending much mental energy on it.
Disclaimer: I'm not interested in journalism myself, it's just an idea.
2 Likes
You can see what's being implemented by tracking commits to the github repo. Organizing the info by canvassing commit messages is left as an exercise for the reader.
1 Like
all right, now i know what to answer my stakeholders when asked about the progress! 
on a serious note, can anyone answer the second half:
i am all for the language feature (e.g. because there is no question which third party library to choose from, which is a big win to me), just want to understand the pros and cons better.
agree. we need a guy like that:
4 Likes
That's fine and could even be automated to be turned into a feed on a website, but that's assuming no one is working on features in a local branch in their PC that don't get pushed into the repo for a long time(or using other remotes). Is that the case?
Thanks, that's a good read!
If you can't see the commits for any reason, they may as well not exist. There's no point at all in worrying about them, and there's no reason to expect to get any kind of regular updates about the status of such forks.
I don't believe there have been any substantial additional discussions - there have been some underlying changes, and more are obviously needed. The focus for 5.x so far has been API stability, binary compatibility and module stability. 6.0 has not yet been started, so there is not yet a stated focus.
I would more items from the ownership manifesto, especially coroutines, to be added before async/await.
I expect there to be influences from LLVM's support for coroutines, C++ coroutines, Rust's async/await, and Objective-C callbacks as well as Actors from languages like Erlang.
Coroutine support in the compiler will likely enable optimizations including inlining coroutine code and reducing copying/reference counting. Coroutine libraries today likely all use thread pools (such as via lib dispatch), spinning the task off to another thread. This adds additional concurrency overhead and concurrency-related issues - coroutines themselves as a language feature will likely not rely on threading themselves at all, and may behave as value types. The scalability will be far better.
Also, first-class language support will likely have better syntax.
Longer term, it is possible features like actors might provide isolation, such that things like a precondition failure terminates an actor rather than the entire process.
6 Likes
David, thanks for your thoughts.
do you think solutions based on green threads (like in Go) can give reasonable overhead and scaleability, on par with what we can achieve at the end of the day inside the language?
Oof 
I could write ten pages on that question easily.
Since you asked what I think personally, I think green threads are generally a bad idea. They are often a portability play in language runtimes/VMs, like Java (which long ago moved from green threads).they make ports an order of magnitude harder as well.
Async/await is easier to implement. IMHO, Golang’s use of green thread techniques came from a feature requirement on how parallelism is represented to the developer.
To the main question - I think emulating coroutines using native threads can provide “acceptable” performance for a lot of applications, but it will hardly be worth comparing to a mechanism handled by the compiler.
it is hard to believe that, given how many years it took for C++/Rust/etc to do coroutines. looking at Gor Nishanov's C++ presentations on coroutines gives you an impression it was anything but easy to implement.
did anyone here try to use C/C++ coroutines from swift? e.g. wrap those inside Obj-C wrapper class and call that from swift, would that fly?
1 Like
Yes, I'll fully admit I took the existing work out there to build upon into account when formulating my opinion.
3 Likes
that one is "green threads" based (setjump/longjump)
it would be interesting to see the (upcoming) C++ coroutines (AFAIK available now in clang) used from within swift... they claim to be "the best coroutines ever" and claim to be interoperable with pretty much everything.
interesting article that favours the (green) thread approach (as in goroutines):
http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
1 Like