On Jul 1, 2017, at 3:31 PM, Rodric Rabbah <rod...@gmail.com> wrote:
>> I’m not sure it would be worth it to force developers down a path of >> configuring actions based on the network ops of the code within, compared to >> simply allowing concurrency. > > I think it will happen naturally: imagine a sequence where the first > operation is a request and the rest is the processing. All such request ops > can be packed densely. It's way of increasing compute density without > exposing users to details. It was just an example of where I can see his > paying off. If all the actions are compute heavy there won't be any > concurrency in a nodejs runtime. Also among the thoughts I have is how one > can generalize this to apply to other language runtimes. > Decomposing a set of network operations to a sequence of requests and operations implies not using any dependencies that use network operations. One convenience of allowing existing languages (instead of a language of sequenced steps) is that devs can use existing libraries that implement these operations in conventional ways. So while it may be possible to provide new ways to organize network and compute operations to maximize efficiency, there won't be a lot of ways to use conventional libraries without scaling based on conventional methods, like concurrent access to runtimes. I'm not sure how you would split out these network vs compute items without action devs taking that responsibility (and not using libraries) or how it would be done generically across runtimes.
