4 ms·
This is exactly my experience as well. If you provide synchronous, blocking interfaces and no concurrency primitives or expectation of non-blocking functions,
by 15155 11y ago
This is exactly my experience as well.
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.
- tinco 11y agoNot to make this discussion personal or anything, I'm curious have you ever worked in Ruby? You say things like "why bother" and "trying to squeeze blood from this turnip" as if you don't understand why someone would love Ruby. 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.