5 ms·

I agree as well. As an outsider who has toyed with Rubinius I wonder how married Rubinius Inc will be to MRI compatibility. I think the task "concurrency to Rub

I agree as well. As an outsider who has toyed with Rubinius I wonder how married Rubinius Inc will be to MRI compatibility. I think the task "concurrency to Ruby" could be made a lot easier if compatibility with MRI wasnt on the table, it would allow them to experiment much more freely, and I for one wouldnt mind having a very ruby-esque lang with great concurrency primitives. Does anyone know if theyve considered that?

mwpmaybe 11y ago
If we can figure out a way to not have to fork a Rubinius-compatible version of each and every Gem...
cremno 11y ago
Well, there is the over 2 yo Rubinius X announcement: http://x.rubini.us/ http://x.rubini.us/ I have no idea what happened to it or if it's even still a thing.
- YorickPeterse 11y ago
  The ideas of Rubinius X will be added to Rubinius 3.0 over time, see the following articles for more info: http://rubini.us/2014/11/10/rubinius-3-0-part-1-the-rubinius-team/ http://rubini.us/2014/11/10/rubinius-3-0-part-1-the-rubinius... http://rubini.us/2014/11/11/rubinius-3-0-part-2-the-process/ http://rubini.us/2014/11/11/rubinius-3-0-part-2-the-process/ http://rubini.us/2014/11/12/rubinius-3-0-part-3-the-instructions/ http://rubini.us/2014/11/12/rubinius-3-0-part-3-the-instruct... http://rubini.us/2014/11/13/rubinius-3-0-part-4-the-system-and-tools/ http://rubini.us/2014/11/13/rubinius-3-0-part-4-the-system-a... http://rubini.us/2014/11/14/rubinius-3-0-part-5-the-language/ http://rubini.us/2014/11/14/rubinius-3-0-part-5-the-language...
  - cremno 11y ago
    Thanks! That's good to know. I'm familiar with these articles but they didn't mention that. In fact part 5 says something entirely else about X vs. 3.0.
    - YorickPeterse 11y ago
      Sorry, should've said "most of the ideas".
dragonwriter 11y ago
> I think the task "concurrency to Ruby" could be made a lot easier if compatibility with MRI wasnt on the table 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?
- jfaucett 11y ago
  You are equating MRI with Ruby. Most would probably agree, still I wonder if that should be the case. If someone came along and fixed some ruby weak points (concurrency, performance, subtle bugs) I would be happy to call it ruby just like we call java java regardless of whether we use openjdk or oracle. At some point that might lead to an actual spec...
  - dragonwriter 11y ago
    > You are equating MRI with Ruby. 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?
    - jfaucett 11y ago
      "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?" 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.

mwpmaybe 11y ago

If we can figure out a way to not have to fork a Rubinius-compatible version of each and every Gem...

cremno 11y ago

Well, there is the over 2 yo Rubinius X announcement: http://x.rubini.us/ http://x.rubini.us/ I have no idea what happened to it or if it's even still a thing.

YorickPeterse 11y ago
The ideas of Rubinius X will be added to Rubinius 3.0 over time, see the following articles for more info: http://rubini.us/2014/11/10/rubinius-3-0-part-1-the-rubinius-team/ http://rubini.us/2014/11/10/rubinius-3-0-part-1-the-rubinius... http://rubini.us/2014/11/11/rubinius-3-0-part-2-the-process/ http://rubini.us/2014/11/11/rubinius-3-0-part-2-the-process/ http://rubini.us/2014/11/12/rubinius-3-0-part-3-the-instructions/ http://rubini.us/2014/11/12/rubinius-3-0-part-3-the-instruct... http://rubini.us/2014/11/13/rubinius-3-0-part-4-the-system-and-tools/ http://rubini.us/2014/11/13/rubinius-3-0-part-4-the-system-a... http://rubini.us/2014/11/14/rubinius-3-0-part-5-the-language/ http://rubini.us/2014/11/14/rubinius-3-0-part-5-the-language...
- cremno 11y ago
  Thanks! That's good to know. I'm familiar with these articles but they didn't mention that. In fact part 5 says something entirely else about X vs. 3.0.
  - YorickPeterse 11y ago
    Sorry, should've said "most of the ideas".

dragonwriter 11y ago

> I think the task "concurrency to Ruby" could be made a lot easier if compatibility with MRI wasnt on the table 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?

jfaucett 11y ago
You are equating MRI with Ruby. Most would probably agree, still I wonder if that should be the case. If someone came along and fixed some ruby weak points (concurrency, performance, subtle bugs) I would be happy to call it ruby just like we call java java regardless of whether we use openjdk or oracle. At some point that might lead to an actual spec...
- dragonwriter 11y ago
  > You are equating MRI with Ruby. 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?
  - jfaucett 11y ago
    "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?" 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.