What I understood the OP to mean, and what I experienced myself, is that a language needs to actively promote (OS-level) async I/O for it to be usable, not just support it. If sync I/O is the default, too many libraries will use it (it's easy and works fine, until it doesn't).
Because Node.js has no threading, async I/O is the only choice. Result: 100% of the libraries are async I/O.
Because Go has M-N threading, all I/O is inherently async for the OS, even if it's sync for the semantic threads. Result: 100% of the libraries are async I/O.
Scala and Java have Futures and all the other goodness you would theoretically need to make async HTTP requests. But, as an example, the official AWS access library (a wrapper around the AWS REST API) is synchronous. Result: communicate with AWS in your backend during a request? Block an OS thread, or write your own AWS library.[1]
Even having async I/O as an option at all splits your language in two. Most libraries will fall in the sync category, and their mere existence lowers the incentive to write an async one. E.g.: if there were no AWS library for Java / Scala, I would be much more keen to write an async one myself. But now? Ah well, // TODO: async, and continue.
This is the beauty of Go and Node.js on the server.
[1] Or choose an unofficial and, I'm rudely assuming, less complete / audited / reliable library.
They do, but they're widely frowned upon in most applications.
They're completely frowned upon in server-related applications.
I've only really seen them used in cheap build scripts, and now with async/await (via Babel's regenerator transformation), I don't even see that much anymore.
If you provide synchronous, blocking interfaces and no concurrency primitives or expectation of non-blocking functions, IO, etc., people will use them.
In languages where concurrency is a built-in, understood pattern (Go, Erlang/Elixir, Haskell*, to name a few) people don't need to care.
Ruby has the worst of many worlds (sync I/O by default, incredibly expensive memory model, incredibly expensive lambdas, first-class functions aren't normally used beyond the "do block"-- nobody is passing them around, chaining, etc.)- I just don't see the reason to keep trying to squeeze blood from this turnip.
Anyway, I do agree with your argument. Unfortunately Ruby is from the generation of programming languages in which I/O was just seen as an api, so the sane thing was to just map to the system api directly.
JavaScript is from that generation as well but got lucky because its requirement to run in the browser forced it to have I/O fully abstracted.
All async I/O functions have a corresponding sync version.
E.g.
const buffer = fs.readFileSync(path);Ruby lambdas are an afterthought and far too expensive to use in the same expansive capacity as you would in JS (or literally any functional programming language).
Couple that with the fact that the community just doesn't care, and again, I ask why bother?
The actor model isn't superior to callbacks in any technical capacity, and understand, callbacks are only a (perceived) problem when you don't have something like a language-level async/await to transform them for you.
edit: Add in the (MRI) GIL, and you've got yourself a fairly serious impediment to writing efficient, concurrent code.
That they never will has more to do with the general attitude of Rails programmers, and their commitment to the REST request/response model. Libraries that offer more flexible interactions are simply not very visible yet.
Slightly related but not relevant now, Ruby 3.0 is expected to have some concurrency construct fundamentally integrated into the language.