Very good talk, but felt like it got cut off? Was that the end of it? How would you place Go and Erlang concurrency models in your table? Going to watch your structured concurrency talk now, Thank you.
1:09:49 this slide, describing ‘cur_work’ as some object that exists under the hood is critical (I think) to understanding the val model that Lucian is suggesting/describing. If the ‘current_work’ isn’t trivial, then an entire execution graph might need to be generated under the hood. I think it’s a valid and potentially useful approach, but might be difficult for people to grasp.
Thank you for the comment. Indeed, the parallel between senders/receivers and the proposed model is not necessarily straightforward. That is mainly because I was just illustrating a sketch of the proposed model. A key intuition for better understanding the analogy, is to realize that in the senders/receivers model we represent concurrent computations through senders (which can be named, and for the proposed model the computations are the actual instructions (which often are nameless). With this intuition in mind, `current_work` and `h_work` correspond to code blocks in the proposed model.
In the example: `when_all(curr_work, h_work)` equals `h.await()`. How would you wait for 2 works or 3, or, more generally, n pieces of work different from curr_work? You ware going to need some kind of `when_all` there. But the example is very trivial and gets away with doing `h.await()`. You cannot do `h.await()` followed by `i.await()`. That would do it sequentially.
Thank you for the comment. Indeed, there needs to be a version of `when_all()` that can operate on multiple pieces of work at the same time. Depending on the capabilities of the language, this may be `(h1, h2, h3).await()`. That is the target for Hylo language (renamed from Val).
Very good talk, but felt like it got cut off? Was that the end of it?
How would you place Go and Erlang concurrency models in your table?
Going to watch your structured concurrency talk now, Thank you.
1:09:49 this slide, describing ‘cur_work’ as some object that exists under the hood is critical (I think) to understanding the val model that Lucian is suggesting/describing. If the ‘current_work’ isn’t trivial, then an entire execution graph might need to be generated under the hood. I think it’s a valid and potentially useful approach, but might be difficult for people to grasp.
Thank you for the comment.
Indeed, the parallel between senders/receivers and the proposed model is not necessarily straightforward. That is mainly because I was just illustrating a sketch of the proposed model.
A key intuition for better understanding the analogy, is to realize that in the senders/receivers model we represent concurrent computations through senders (which can be named, and for the proposed model the computations are the actual instructions (which often are nameless).
With this intuition in mind, `current_work` and `h_work` correspond to code blocks in the proposed model.
In the example:
`when_all(curr_work, h_work)`
equals `h.await()`.
How would you wait for 2 works or 3, or, more generally, n pieces of work different from curr_work? You ware going to need some kind of `when_all` there. But the example is very trivial and gets away with doing `h.await()`. You cannot do `h.await()` followed by `i.await()`. That would do it sequentially.
Thank you for the comment. Indeed, there needs to be a version of `when_all()` that can operate on multiple pieces of work at the same time. Depending on the capabilities of the language, this may be `(h1, h2, h3).await()`. That is the target for Hylo language (renamed from Val).