Second, I would not say Ruby is not a language for the multi-core world. There are tens of thousands Ruby production environments over the world that make excellent use of multi-core machines. They run Ruby on problems that are embarassingly parallel such as web applications using process managing application servers such as Phusion Passenger or Unicorn. This is the way many modern web application platforms parallelize, including Node.JS and Python.
Third lack of paralellization is not a language feature. Both JRuby and Rubininus support threads without a GIL. Projects like Celluloid and Concurrent-Ruby make use of this.
2.Passenger and Unicorn are multi-process, which due to developers can make use of nearly nothing in Ruby, and that's why gems like https://github.com/grosser/parallel come out.
3. The language implementation detail matters a lot. Too many gems are not thread-safe. JRuby is an option, but not that good, as there're too many other options under JVM platform. Rubininus is awesome, I wish it comes out earlier.
MRI isn't the implementation for the multi-core world, but MRI isn't the only Ruby implementation; on language features, JRuby, particularly, isn't particularly far behind (the current version runs Ruby 2.3 code; I wouldn't expect 2.4 support to be that far behind), and fully supports thread-based parallelism.
Not really; it depends on the audience. The Ruby audience is still mainly Rails development, whose paradigm is multi-process.