I don't really feel like the second of those is a good description, since it presents a false symmetry. Rubinius is trying to have solid support for good concurrency models in something that is actually Ruby.
Elixir is trying to have something vaguely Ruby-like that builds on existing support for strong concurrency models on the BEAM VM.
Obviously, the latter is an easier task, as it is less constrained (both seek strong support for concurrency, the former seeks being Ruby, the latter seeks only weak resemblance to Ruby), but the former leverages a greater subset of Ruby's existing strengths, including its existing ecosystem.
If compatibility with MRI isn't on the table, its not really "concurrency to Ruby", its "concurrency to something that is not entirely unlike Ruby", which is a different thing, and at that point, why even consider Ruby as a touchstone at all, rather than an inspiration (the way Elixir does) since you aren't going to be able leverage the existing ecosystem?
As far as there is a practical definition of "Ruby", MRI (which actually has, since 1.9, been YARV, a previous compatible-with-MRI alternative implementation) is it.
> If someone came along and fixed some ruby weak points (concurrency, performance, subtle bugs) I would be happy to call it ruby
If it wasn't compatible with existing Ruby and you couldn't use existing Ruby with it, why would you be happy to call it Ruby?
> just like we call java java regardless of whether we use openjdk or oracle.
OpenJDK's relation to Oracle's JDK is more that between Chromium and Chrome than that between Ruby and an alternative and incompatible-but-similar language from a third party.
> At some point that might lead to an actual spec...
Like ISO/IEC 30170:2012?
Im happy calling clojure a Lisp? Why not call this new 95% similiar language by what it is - a Ruby? If it were 20-25% similar (elixir) or even 60% I could call it ruby like X lang and be done. Thats not what the point Ive been trying to make though.
When is an object a bowl and not a cup? Is it when it loses its handle? What about if it has a handle but is wide and open and deep? I personally dont think its as binary as your making it out to be (100% compatibility yes/no). If this were the case there would a canonical Lisp and no one else could refer to a lisp as such.
"Like ISO/IEC 30170:2012?" No, that hasnt been revisited since 2010 was for ruby 1.8.7, and doesnt include the whole standard library, which means if you want to accept that youd have to throw out your argument because by your very definition it couldnt be a spec for a Ruby since it doesnt include all exact behavior like mri.
This has been tried before. By Rubinus, in fact.
I have no idea what happened to it or if it's even still a thing.
(Unless exilir compatibility with rails approaches that of rubinius)
So between JRuby and Rubinius I choose JRuby because I've used it in the past and it's great. The fact that JRuby folks try super hard to maintain compatibility is also really nice. I want to know who is actually using Rubinius and in what capacity and why.
Elixir is already being pickup up for real projects
but I feel like Rubinius has only ever been a play thing.
Open source is great, and it has its place. But it's not the future. Healthy competition drives innovation behind closed doors, and people should be allowed to profit from their own work without giving it away for free.
By "people", do you mean "developers", or "capital"?
As a software developer I am well-compensated compared to people in many other professions, but unless I play the startup lottery I'm as isolated from the investor class as the rest of the proles.
Publishing work as open source allows me to get a better ROI than I get working on proprietary code.
The FSF point about charging for distribution seems to be mostly an artifact of the time before software distribution was commoditized/made free.
(Same goes for SteveKlabnik below).
1. Charge for running the service.
2. Take a cut of transactions over the service.
3. Charge for feature additions.
4. Charge for installation/configuration/support/maintainance.
5. Patreon-style support (including Patreon).
6. Sell physical media & merchandise (don't laugh, ask a band).
Now, about how proprietary software companies can ever hope to compete with Google even if they don't lose all their revenue to piracy...
There are tons of ways to make money in open source. I just don't think they're selling software that could be torrented. It's really a pretty trivial point, and one I maybe shouldn't have bothered to make--I just got in a pedantry skirmish.
I'm kind of curious how, even if people are allowed to profit, they'll be able to. Consider Wikipedia, OpenStreetMaps, and Linux.