You may not be familiar with the Ruby ecosystem, but its not really fragmented.
It's founder Matz (Yukihiro Matsumoto) originally wrote it in C, but other projects (like JRuby, Rubinius, etc) still defer to Matz's design, though they may not have all its functionality. However, most people in the community don't see this as fragmentation in a negative sense, but variations on a theme.
So Crystal seems to want to be Ruby-like in look, feel, and use, but provide users a closer relationship to the hardware.
Elixir (http://elixir-lang.org/), created by a former Ruby on Rails (RoR) developer, wants to leverage Erlang's Functional Programming (FP) and concurrency features into a Ruby-like feel and use.
Since MRI (Matz's Reference Interpreter) Ruby is written in C, and Rust is supposed to be a better C (system development language) there should be no theoretical reasons it couldn't be used to write Ruby in (assuming when Rust becomes stable).
Of course, just writing a 1-to-1 replacement of C with Rust wouldn't be that interesting (to users).
However, Rust could bring to the game a better/secure way to do realistic parallelism, faster executions, and maybe lesson the need for (or speedup) garbage collection (GC).
As a Ruby user, and a Rubgem creator (primes-utils | RubyGems.org | your community gem host) I would love an easy way to get to bare hardware within standard Ruby to get parallelism, et al, without having to use (and rely on) JRuby to get some of those features.
Ruby is currently at 2.3, but 3.0 is currently in early, early development. Matz is trying to figure out how to (and to what extent) remove its GIL (Global interpreter lock - Wikipedia ) to allow general concurrency/parallelism within the core language. I can't help but think that Rust would be able to allow this to be done better than C.
So anyway, I just threw out the idea for fun, but maybe someone with play with doing it.
