Rubinius, Inc. – A Benefit Company | Hacker News Reader

Rubinius, Inc. – A Benefit Company

rubini.us

110 pointskyledrake44 comments

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.

Exilir 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)

Personally, 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.

Not totally sure what you mean. Elixir will never run rails, but the phoenix framework has some similarities to rails.

> has some similarities to rails.

LOL

I 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.

Will 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?

I agree.

Elixir is already being pickup up for real projects but I feel like Rubinius has only ever been a play thing.

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?

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

Well, there is the over 2 yo Rubinius X announcement:

http://x.rubini.us/

I have no idea what happened to it or if it's even still a thing.

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...

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-instruct...

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...

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.

Sorry, should've said "most of the ideas".

> 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?

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...

> 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?

"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.

> At some point that might lead to an actual spec...

This has been tried before. By Rubinus, in fact.

> 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.

As 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.

Don't you say the syntax isn't there to attract ruby fanboys, or else why not just use Erlang.

Tooling (mix, Hex, ExUnit), macros, Protocols for polymorphism, more natural feeling APIs in the standard library.

I'm interested to see how Brian will approach a business model built on open source. The most common ways to do it (selling a "pro" version of software that is closed source, running a hosted version, or selling support) all fall short for me in various ways. I'd love to see an approach that maintains the user's privacy and control.

Slightly related, the Phusion guys (who made Passenger) did a keynote at OSCON today on that very topic: https://www.youtube.com/watch?v=CpyRlaWmZg4

How does a benefit company affect things like funding? Or acquisition if the time comes?

The description here is pretty good: http://benefitcorp.net

It's too bad they didn't choose to pursue the full on B Corp Certification. In many jurisdictions, benefit corp is just a box you tick.

I wonder if the IBM Method JIT CRuby replacement will get any concurrency features.

> Open source is the future

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.

Though it may often be, open source software does not have to be free of cost. As the FSF says: free as freedom, not free as in beer.

Backing up hyperpape, here's the word from the horse's mouth https://www.gnu.org/philosophy/selling.html

hyperpape makes a good point about this tho

Absolutely, just providing the citation.

That's true, but not enough--you have to explain how that enables a revenue model for a modern company. How many companies make money selling open source software (not support, not feature development, not proprietary forks based on copyright assignment) without using the Red Hat model?

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).

There are any number of ways to get paid for your labour as a hacker.

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).

etc.

Now, about how proprietary software companies can ever hope to compete with Google even if they don't lose all their revenue to piracy...

Try to apply that model for desktop/native software to average Joe on the street.

None of this is responsive. I should've been more explicit that what I described didn't include hosted services, but it doesn't.

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.

Most of those aren't getting paid for your labor as a hacker, which is to say, a programmer. They're getting paid for support, for ops, for server time -- number 3 is the only one that directly pertains to writing code. So you can monetize ancilliary activities, but the act of giving source code away for free devalues the act of actually writing source code and makes it difficult to monetize the writing of source code itself, not the ancilliaries.

> and people should be allowed to profit from their own work without giving it away for free.

I'm kind of curious how, even if people are allowed to profit, they'll be able to. Consider Wikipedia, OpenStreetMaps, and Linux.

Consider Linux, MySQL, PHP, and then consider Facebook.

Facebook is a scary example. Facebook is 1% open source contributions funded by 99% proprietary walled garden. Scaled down to something like rubinius, the scale fraction would be something like working a proprietary company/job all year and writing some open source on vacation days.

> people should be allowed to profit from their own work

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.

Of course it is. People don't realize that software no matter how good if it is proprietary has a limited shelf-life. It might make you rich in the short term but ultimately it will go into the dustbin of history. That's because software on its own is worthless. It is the people, processes, and institutional knowledge around it that is valuable and once a set of practices and processes is common enough to automate with software the free and open-source version will always win.

Reply on news.ycombinator.com