I've used them both and found rbenv's Just Works factor to be higher for me, personally. There's definitely enough people out there using both tools that neither can be said to be the one that "everybody is already using".
:) I mean "everybody is already using" in the context of most dev area, including my own.
Here's how it usually works: We're coasting along with some tool and doing well, then some dev announces that we're ALL WRONG because another tool is better. Sometimes the tool he's announcing is something like git when we're using TFS, and we switch. Other times, say RVM vs. this right now... I just don't see a big gain.
I hear you. I never had any "real" issues with RVM other than I probably never really learned how to use it, so it kept tripping me up. (I'm not very good at this stuff..)
I was setting up a new computer a few months ago and decided to give rbenv a try and it hasn't given me any reason not to like it so far. Just guided someone on the west coast who has never worked with Ruby before through installing it and getting her first Rails project up and running last night, via approximately 65 emails. Does that make me an advocate?
I'm not saying it's always the rule. It depends on the context. If the context is a group of Ruby/Rails devs who are efficiently building applications in exchange for money, and the new(er) tool is one that:
1.) Ends with the same net result for the developer, and
2.) Adds a little bit of complexity on setup and rules around use, then
why switch? I'm perfectly willing to trade up my development tools, but I want a better net gain before I switch.
Perhaps that net gain will be to keep up with a growing number of devs who use it? We'll see.
You can use the right tools in the wrong way and be productive. You're still using them wrong. Most people use Bundler and RVM gemsets in a way that Bundler wouldn't even be needed. Rbenv forces you to learn the proper way of project management and it actually reduces complexity once people get over the small learning curve of using the correct tools for each thing. Bundler manages dependency, Rbenv just switches rubies. RVM adds so much more that it blurs the lines between things.
> Rbenv forces you to learn the proper way of project management and it actually reduces complexity once people get over the small learning curve of using the correct tools for each thing.
Boy did you overreach on this one. What about rbenv constitutes the "proper way" versus a tool like RVM? If the argument is that RVM abstracts away too much of the underpinnings, then you've just a made a philosophical argument that is in conflict with much of the work that we do as developers.
RVM is simply an environment manager. One should always understand the environment that they're managing, but using tools to increase the efficiency of that management is not in violation of the "proper way". If abstraction of underlying complexity is bad, we shouldn't be using bundler, rbenv, or even init scripts and package managers. We should start all system processes with the direct invocation and build and install software by hand, lest we not learn the "proper way".
If we accept that abstraction is not necessarily a bad thing, then we can recognize that there's nothing about rbenv that is any more "proper" than RVM, and we can all use the tools we prefer.
I prefer not to have to append '--path=./somedir' every time I run `bundle install`.
I prefer not to have to prepend 'bundle exec' to every shell tool in my toolchain.
I prefer to have all my rubies and gemsets organized in a single location instead of spread out across my projects.
I understand that by using RVM a background process is altering my environment. I also know how to run `rvm info`, read the output, and understand the terms.
Those are my preferences. They're no more right (or wrong) than yours.