Live data from Hacker News

Engine Yard's sponsorship of RVM is coming to an end

rvm.io

1–10 of 72 posts

Re: Engine Yard's sponsorship of RVM is coming to an end

#3
post #2

The conversation at https://www.bountysource.com/fundraisers/489-rvm-2-0 has a lot more meaning to it, primarily why RVM vs. rbenv vs. chruby all deserve to exist. As for me and mine, I'm in the land of docker now...

How does Docker fit in with Ruby version management software?

Re: Engine Yard's sponsorship of RVM is coming to an end

#4
post #2

The conversation at https://www.bountysource.com/fundraisers/489-rvm-2-0 has a lot more meaning to it, primarily why RVM vs. rbenv vs. chruby all deserve to exist. As for me and mine, I'm in the land of docker now...

I actually think that the "RVM vs. rbenv vs. chruby" section of the BountySource page is pretty bad. There's almost no argument there, just that there are certain scenarios in which RVM "does a lot more to make handling [them] easy". What scenarios? In what situations would a "complex environment" or set of dependencies make RVM a choice that I'd "be a fool to not go with"? My experiences has been that a complicated tool like RVM makes for a _more_ environment, not one that's easier to work with.

Additionally, some of the schedule on that BountySource campaign makes me especially wary. If most of the code is rewritten in Ruby, presumably it would need to build/install Ruby during its own installation so it can be used afterwards. If the GUI relies on JRuby, it would need to build that during installation as well. Suddenly RVM becomes less easy to install.

Re: Engine Yard's sponsorship of RVM is coming to an end

#5
post #2

The conversation at https://www.bountysource.com/fundraisers/489-rvm-2-0 has a lot more meaning to it, primarily why RVM vs. rbenv vs. chruby all deserve to exist. As for me and mine, I'm in the land of docker now...

For those curious, what that page by rvm authors suggests is that:

> Tools like rbenv or chruby can work well in simple scenarios, especially if you’re very skilled with the Unix shell. However, as environments and dependencies grow in complexity, these tools quickly become inadequate. RVM seems more “complicated” because it does a lot more to make handling these scenarios easy.

> To paraphrase Jonathan Jackson, RVM is to Rails as rbenv is to Sinatra. Sinatra is a lightweight framework whereas Rails is much more robust. Sometimes Sinatra just fits, and other times you'd be a fool to not go with Rails.

I think people with complicated scenarios have had... mixed experiences with whether rvm really makes complex scenarios easy. I suspect many people with complex scenarios prefer a simple tool like rbenv or chruby (disclosure: I prefer chruby having worked with all three), which they can then figure out themselves how to invoke to do exactly what they need.

It may be that some people with complex scenarios prefer rvm. It would be interesting to hear from them. (for real! I'd be interested!)

But I suspect that the bulk of rvm users are not actually sophisticated users with complicated scenarios, but instead beginner users with fairly simple scenarios. For a variety of reasons. Becuase rvm is what you find when you google. Because rvm holds out the promise of not making you understand anything about what it's doing or anything about bash or shell environment, and having it Just Work (whether it fulfills that promise... especially in non-simple scenarios... there are mixed opinions. There are definitely some people who have moved from rvm to rbenv or chruby in fact as their environments have grown in complexity, and they had trouble figuring out how to get rvm to work in their environments. ).

People try to be really sensitive not to insult rvm. And I've tried to be sensitive here, while still saying what I perceive. Lots of people like rvm, for sure. And rvm was first, and a huge boon compared to the no options that preceeded it. And nobody wants to be rude, or get into a fight. But people's sensitivity and desire to avoid controversy also means when you google around... you pretty much just find rvm, even though some (many? I don't know) have in fact moved from rvm to chruby and rbenv -- including sometimes moving as their environments become more complicated.

I am not sure it's accurate to say that developers routinely find chruby or rbenv "quickly become inadequate" as environments and dependencies grow in complexity ('quickly'? really?).

Re: Engine Yard's sponsorship of RVM is coming to an end

#6
post #3
post #2

The conversation at https://www.bountysource.com/fundraisers/489-rvm-2-0 has a lot more meaning to it, primarily why RVM vs. rbenv vs. chruby all deserve to exist. As for me and mine, I'm in the land of docker now...

How does Docker fit in with Ruby version management software?

Simple, each ruby version sits in it's own container

Re: Engine Yard's sponsorship of RVM is coming to an end

#7
post #3
post #2

The conversation at https://www.bountysource.com/fundraisers/489-rvm-2-0 has a lot more meaning to it, primarily why RVM vs. rbenv vs. chruby all deserve to exist. As for me and mine, I'm in the land of docker now...

How does Docker fit in with Ruby version management software?

It removes the question of version management altogether by isolating an app's environment. Not too shabby an idea, especially now that Vagrant is available.

Re: Engine Yard's sponsorship of RVM is coming to an end

#8
post #2

The conversation at https://www.bountysource.com/fundraisers/489-rvm-2-0 has a lot more meaning to it, primarily why RVM vs. rbenv vs. chruby all deserve to exist. As for me and mine, I'm in the land of docker now...

Docker is a bit orthogonal, IMO. One key problem these tools solve is getting a specified version of ruby onto a host at a granularity other that "whatever's in my distro's package repo". It's certainly possible to simplify matters and just use ruby-build[1] to normalize ruby acquisition. AFAICT, this is out of scope for Dockerfiles in recent incarnations.

[1] https://github.com/sstephenson/ruby-build

Re: Engine Yard's sponsorship of RVM is coming to an end

#10
I hate (yes, it's that strong a word) the problems related to versioning in Ruby ... and even with RVM, you have to figure out which gems are compatible. My solution is to get rid of my Ruby applications. I'm not a Ruby developer, and my career path isn't likely to afford me the time to really learn it.

I'm a Java developer, and we have our own version of dependency hell (that I've learned to avoid and/or navigate), so I'm not trolling, but rather wanted to point out that often issues like dependency management (there are others) simply cause marginal developers to leave.

Post reply on HN