10 ms·
I feel bringing concurrency to Ruby (what Rubinius is trying to do) is going to be harder than bringing Ruby to concurrency (what Elixir is trying to do). Addin
by sinatra 11y ago
I feel bringing concurrency to Ruby (what Rubinius is trying to do) is going to be harder than bringing Ruby to concurrency (what Elixir is trying to do). Adding Ruby-like syntax on top of fundamentals like functional programming, immutability, etc (which are naturally suited for concurrency) sounds like a better approach to me. Would love to hear others' opinion.
- deleted 11y ago[deleted]
- fleitz 11y agoExilir is exactly the better approach, sadly worse is better, so rubinius is the approach that will get the most adoption. (Unless exilir compatibility with rails approaches that of rubinius)
- sanderjd 11y agoPersonally, I don't find the library gap between ruby/rails and elixir/phoenix for simple web applications to be particularly onerous already, and it will only get better.
- mrinterweb 11y agoNot totally sure what you mean. Elixir will never run rails, but the phoenix framework has some similarities to rails.
- issaria 11y ago> has some similarities to rails. LOL
- dkarapetyan 11y agoI don't think worse is better applies here. There's also JRuby and rubinius is in a weird limbo state where it's not quite Ruby like JRuby and it's not quite another language like Elixir. Similar thing happened to Dart I think. It was stuck in limbo and never got adoption. 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.
- adamkittelson 11y agoWill it? My knee-jerk reaction to this was that Elixir already has more adoption than Rubinius, but then I stopped paying attention to Rubinius years ago. Do people use it for real stuff?
- matthewrudy 11y agoI agree. Elixir is already being pickup up for real projects but I feel like Rubinius has only ever been a play thing.
- jfaucett 11y agoI 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 agoIf we can figure out a way to not have to fork a Rubinius-compatible version of each and every Gem...
- cremno 11y agoWell, 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 agoThe 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 agoThanks! 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.
- dragonwriter 11y ago> I feel bringing concurrency to Ruby (what Rubinius is trying to do) is going to be harder than bringing Ruby to concurrency (what Elixir is trying to do). 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.
- rubiquity 11y agoAs I have to in every post about Elixir on HN, I'm going to say it again: Aside from some syntax, Ruby and Elixir have nothing in common.