Feels like the elephant in the room for the description is not once mentioning Futures but instead jumping straight to using async / await keywords and the actor model.
As evidenced by C#, you can't avoid leaking the type signature of async operations if you actually support generic programming- so while that's a nice ergonomics improvement, it only adds complexity to the actual concurrency model. Go enthusiasts out there will appreciate that go solves this by refusing to support PROGRAMMABLE generic abstractions at all (looking at you, channels and map).
Referencing the actor model and making it first class is interesting, but probably a mistake. Actors are hard to reason about because they're so flexible. Pony is a good recent attempt at combining static types with actors, bit they didn't put performance into the "non-goals" section of their language spec.
If you want task level concurrency and you want it to play nice with your type system, you have to start with Scala and work backward to the alternative implementation choices you're going to make because it checks all the boxes of all the "goals" and ALSO has a very mature actor model implementation that doesn't require promoting actors to keyword status in the language.
Forgive my naivety, but parent article seems to contradict the github post linked in your reply in quite a few ways. What is the time / design iteration relationship between the two, and why (not to put you on the spot)? These are VERY different proposals.
One spec is about Async/Await and the other is a high level design approach for the language (which does include a reference to the async/await proposal, its under the section titled `Part 1: Async/await`).
The part where the execution graph is "linked" at runtime into an actor graph. It's hard to reason about because it's flexible enough to enable large numbers of possible combinations.
I'm not saying it's bad, but I am saying that the flexibility limits the ability to reason about actor interactions (especially concurrent interactions), which makes it akin to the dynamic vs static type system debates. One is strictly more flexible than the other, and that necessarily makes it harder to reason about.
Actor systems can be racy and so to reason about them you may need to consider things like the order messages are delivered - which you can't always do.
Comments
Feels like the elephant in the room for the description is not once mentioning Futures but instead jumping straight to using async / await keywords and the actor model.
As evidenced by C#, you can't avoid leaking the type signature of async operations if you actually support generic programming- so while that's a nice ergonomics improvement, it only adds complexity to the actual concurrency model. Go enthusiasts out there will appreciate that go solves this by refusing to support PROGRAMMABLE generic abstractions at all (looking at you, channels and map).
Referencing the actor model and making it first class is interesting, but probably a mistake. Actors are hard to reason about because they're so flexible. Pony is a good recent attempt at combining static types with actors, bit they didn't put performance into the "non-goals" section of their language spec.
If you want task level concurrency and you want it to play nice with your type system, you have to start with Scala and work backward to the alternative implementation choices you're going to make because it checks all the boxes of all the "goals" and ALSO has a very mature actor model implementation that doesn't require promoting actors to keyword status in the language.
He heavily discusses Futures, and a sudo-implementation, in the full proposal here: https://gist.github.com/lattner/429b9070918248274f25b714dcfc...
pseudo
sudo is something different
Forgive my naivety, but parent article seems to contradict the github post linked in your reply in quite a few ways. What is the time / design iteration relationship between the two, and why (not to put you on the spot)? These are VERY different proposals.
One spec is about Async/Await and the other is a high level design approach for the language (which does include a reference to the async/await proposal, its under the section titled `Part 1: Async/await`).
He links this "full" proposal, in the proposal linked by OP. That's how I found it
What part of actors are hard to reason about?
The part where the execution graph is "linked" at runtime into an actor graph. It's hard to reason about because it's flexible enough to enable large numbers of possible combinations.
I'm not saying it's bad, but I am saying that the flexibility limits the ability to reason about actor interactions (especially concurrent interactions), which makes it akin to the dynamic vs static type system debates. One is strictly more flexible than the other, and that necessarily makes it harder to reason about.
Cool, yeah I see what you're saying - thanks.
Actor systems can be racy and so to reason about them you may need to consider things like the order messages are delivered - which you can't always do.