Half Baked Co-Data In the sense that CoRoutines make use of the abstraction of suspendable functions as a way of marking and making explicit the 'lines' where concurrency (the concept) meets dispatching and suspension (the implementation) to weave a cohesive model of concurrent _Execution of control flow_, while leaving the implementation of _Data_ largely untouched -- Perhaps 'Co-Data' (tm)(r) might make use of the abstraction of _transportable_ data structures as a way of marking and making explicit the 'lines' where proximity (the concept) meets serialization and _transportation_ of data (the implementation) to weave a cohesive model of concurrent or 'co-spacial ' _Data Flows_ ... Fancy talk -- for -- What would it look like if we took the concepts of Kotlin 's implementation of CoRoutiens and applied it to RPC, services, Caching/Data-proxies etc to allow one to program 'as if' data were 'co-resident' in the same freedom as one can program that suspending functions are sequential. This is not new by any means. (a recent example being the 'live data' structures in reddison, older examples being EJBs, message bus's and the concept of write-through or read-ahead caches in general, data mapping/binding etc. With Kotlin we have an opportunity that is historical rare -- the potential for a common ubiquitous language for both control flow and schemes/data that 'crosses' domains' (native/browser/server/mobile/ as well as other domain dimensions) -- one that might possible gain enough critical mass to be widely adopted. What would it look like if a co-routine could invoke a suspending function that _May Execute_ in another process, hardware , VM, across the world, bottom of the ocean. Would that benefit by a transparent 'transport' of the Data along with the control flow so programmers are freed from concerns with serialization, data mappings etc as they are with control flow and suspension with co-routines ? Of course one cannot be fully free -- as the nature of problem is inherantly that the domains may not be directly accessable from each other -- (no direct 'pointer to memory in another process/cloud/IOT device' -- but is that so different from the abstractions built on routines like Actors and Flows ? Could a 'remote dispatcher' be just another co-routine dispatcher ? I imagine one would have to annotate data as we do functions to indicate to the compiler what data needs to be 'potentially transportable' -- rougly analogous to the various forms of 'IDL' used today for automated client/server stub generation and data marshaling. Essentially a blending of the 'state of the art' of decoupling flows from temporal constraints and data from location/proximity constraints. There are working systems (even in kotlin) that implement similar idioms (e.g Vert.x, Corda) -- taking advantage of either pre-shared code (jars) or dynamically distributed (serialized lambdas) -- Would such a beast help or confuse the development of 'full stack' apps -- where 'full stack' could be expanded in meaning to 'wherever the data flows' -- including 'cold flows/cold data' (simply 'freezing' a flow mid-stream along with its data into some cold storage -- to be reanimated in some future time and place -- similar to an application & data & installer & runtime bundled Could transpirling architectures like Vaadin (evolved from GWT) or TypeScipt evolve to code *and data* that simply 'doesn't care' where it resides ? Not 'pre destined' to be Browser or Server, Mobile or Cloud, active or passive. We have all this today -- but its manual, and convention and complex tooling, everything *but* seamless and transparent and simple. We see glimpse of this coming from Microsoft and Apple and Google and AWS -- but all of those trade ease of application writing for complexity/dependency of ecosystem -- *tightly* bound to the vendor and platform. Thats not bad on its own -- but its *heavy* ... in the sense of the application requiring an entire virtualized ecosystem -- maybe the Kotlin Way wouldn't require that ? Maybe it could ride lightly on existing infrastructure as it does today with Native/JVM/JS -- Ending as I began -- this is Have Baked -- not even a 'Proposal' but maybe a "Meta Proposal'? An idea that might take form ?