3 ms·
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 acto
by haimez 9y ago
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.
- andrewbarba 9y agoHe heavily discusses Futures, and a sudo-implementation, in the full proposal here: https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619#entering-and-leaving-async-code https://gist.github.com/lattner/429b9070918248274f25b714dcfc...
- haimez 9y agoForgive 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.
- andrewbarba 9y agoHe links this "full" proposal, in the proposal linked by OP. That's how I found it
- ash_gti 9y agoOne 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`).
- anentropic 9y agopseudo sudo is something different
- staticassertion 9y agoWhat part of actors are hard to reason about?
- haimez 9y agoThe 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.
- staticassertion 9y agoCool, yeah I see what you're saying - thanks.
- chrisseaton 9y agoActor 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.