Here’s the proposal for a concurrency model in Ruby 3. I think this looks pretty great. What are your thoughts?
http://www.atdot.net/fp_store/f.iu25do/file.2016_rubykaigi.pdf
Appears to have moved → http://www.atdot.net/~ko1/activities/2016_rubykaigi.pdf
It looks neat, however I would personally not be too bothered about Ruby 2 compatibility, particularly if it means performance won’t be up to a par with other concurrent languages like Elixir/Erlang.
I think people love Ruby so much that they wouldn’t mind having to re-write some parts of their program to upgrade it to Ruby 3 (if it wasn’t R2 compatible).
That’s my personal thoughts anyway 
I agree. Jruby+Truffle+graal will push ruby 2 really hard and will keep it competitive.
In the meantime is love for ruby 3 to explore actor concurrency, optional types, maybe some more functional stuff. More scala, more erlang, less perl, less ruby 1.8, and the same sort of friendliness in the language that its known for. Ruby is really good at sort of making it possible for me to solve the problem in my head, write THAT instead of a bunch of other ceremonious crap just to get things working.
Of course there are some benefits to backwards compat, python nerds can certainly teach us here, but I think future jruby largely mitigates the risk of a bunch of rails junk having to be rewritten. Depending on how deviation there is, it could even be possible to port ruby2->ruby3 or at least do the hard parts.
I don’t want compatibility to hold back the language. If we do that, we’re Java.
File not found?
Appears to have moved? → http://www.atdot.net/~ko1/activities/2016_rubykaigi.pdf?utm_source=rubyweekly&utm_medium=email
This smells a lot like CSP (https://en.wikipedia.org/wiki/Communicating_sequential_processes) with their channels and transfers.
In CSP each process can be run in parallel. A process can be made of multiple processes. Processes can communicate data with each other over channels.
Very much so. Crystal adopted CSP for basic concurrency too.