3 ms·
The choice of I/O model has nothing to do with Ruby (see eventmachine for a commonly-used evented NIO setup). If you want asynchronous io with an event-driven
by andrewmutz 11y ago
The choice of I/O model has nothing to do with Ruby (see eventmachine for a commonly-used evented NIO setup). If you want asynchronous io with an event-driven model, there are good options for most languages.
- 15155 11y agoIt 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.
- howabouta 11y agoMatz doesn't do good IO, so we don't do good IO.