Re:Render realtime RethinkDB results in React
by 15155 on Saturday July 04, 2015 @02:09PM
(#9830984)
It has everything to do with Ruby.
With Go, Node.js, Erlang/Elixir, you don't enter the stage assuming that every operation you do is actually going to block others.
Concurrency is not a first-class concept in Ruby (nor Python).
Yes, EventMachine exists. Ok, it's not the standard nor norm, and I would wager most Ruby programmers have heard of it but haven't actually used it.
Even if you're using EventMachine or Twisted, those technologies are infectious (by necessity, not complaining here)- everything you build or use needs to utilize those primitives to work successfully.
In Node.js, the assumption is that nothing will block a calling thread (in favor of asynchronous callbacks).
In Go, the assumption is that goroutines (via a semi-preemptive scheduler) will not block their caller.
In Erlang, the assumption is that processes will not block one another (with a fully preemptive scheduler).
As a fan of Node.js- I will state, not having a widely-accepted, standard interface for building concurrent programs (vs. the soup of callbacks/Promises, associated async/await implementations, coroutines via generator functions) has been a severe detriment to the community.
With Go, Node.js, Erlang/Elixir, you don't enter the stage assuming that every operation you do is actually going to block others.
Concurrency is not a first-class concept in Ruby (nor Python).
Yes, EventMachine exists. Ok, it's not the standard nor norm, and I would wager most Ruby programmers have heard of it but haven't actually used it.
Even if you're using EventMachine or Twisted, those technologies are infectious (by necessity, not complaining here)- everything you build or use needs to utilize those primitives to work successfully.
In Node.js, the assumption is that nothing will block a calling thread (in favor of asynchronous callbacks).
In Go, the assumption is that goroutines (via a semi-preemptive scheduler) will not block their caller.
In Erlang, the assumption is that processes will not block one another (with a fully preemptive scheduler).
As a fan of Node.js- I will state, not having a widely-accepted, standard interface for building concurrent programs (vs. the soup of callbacks/Promises, associated async/await implementations, coroutines via generator functions) has been a severe detriment to the community.