> Difference of opinion, Golang seems to do as is your opinion, Haskel builds > everything on MVar's, and F# has both async and task parallelism with the > Task type it gets from DotNet including the FlowVar concept, but with those > Task's able to work together with Async. F# doesn't have built-in channels, > so if required on would have to build them from primitives. > > My opinion could be changed if the version of FlowVar's I propose truly can't > work with a version of async, but I'd like to see the implementation as by F# > researched first.
The main reason why I think channels should be a primitive building block is that it can be implemented in hardware on message-passing-based hardware or cluster-on-chips: * Intel SCC had hardware channels [https://en.wikipedia.org/wiki/Single-chip_Cloud_Computer](https://en.wikipedia.org/wiki/Single-chip_Cloud_Computer) * I assume Tile CPUs from Tilera/EzChip/Mellanox/Nvidia (successive acquisitions by a bigger fish) also have hardware channels [http://web.mit.edu/6.173/www/currentsemester/handouts/L18-tilera-multicore.pdf](http://web.mit.edu/6.173/www/currentsemester/handouts/L18-tilera-multicore.pdf) * Similarly for Adapteva 1024 cores RISC network-on-chip CPU: [https://www.parallella.org/docs/e5_1024core_soc.pdf](https://www.parallella.org/docs/e5_1024core_soc.pdf) * You can reuse Infiniband or MPI channels as primitives for distributed computing. Adding async support on top of a channels only requires adding a way for the channel to return control the event loop. If channels use `tryRecv` and `trySend` it's easy to add a `poll()` or equivalent callback to the event loop. In all languages (Go, Nim, ...) channels are built either on top of Lock+Condition variables or Atomics (reusing queue designs) but I expect we will reach the limits of memory coherency at the CPU level and that in the future NUMA will become increasingly important and we might see hardware channels being more popular (rather than restricted to stuff like Infiniband)
