Hacker News Reader

> You are installing something that by it's nature requires a bit more understanding that just clicking on a .exe.

Well the default installation shouldn't. The default installation should be for someone who just wants to try Ruby out, that will just set things up to work, and won't interfere with anything else on the system (except for integrating with the webserver you're using). Like PHP does. Then they can mess around with Ruby, and as they learn about it, go back and change the installation or re-install as necessary.

> Do you trust an automated installer to be able to do it reliably on every single machine?

Well, yeah. Isn't that what installers are for? They're written by the team that developed the software. I assume they have a much better idea of how to properly install it than I do!

But is RVM really that hard? If you are on a major distribution of Linux or OSX, all you have to do is install the dependencies and then copy and paste the bash command that setups up RVM.

The hangup is usually installing the dependencies. I remember on Ubuntu this involved hunting down one library that wasn't listed on the RVM wiki. Maybe that needs to be fixed with either more documentation on the RVM wiki or a Ubuntu RVM package (that package probably already exists).

On OS X it requires getting GCC to work, again maybe that needs to be clearer on the RVM wiki.

On windows - well on windows I just install a Ubuntu VM and go back to that installation.

But fixing those simple things (documentation, possibly RVM package) is far easier than creating a whole new installation process.

I agree that there must be a better way, but I need to point it out.

Ruby does come with Mac. Ruby is not Rails. The default installation allows anyone to try Ruby.

Sure, and if it's nicely sandboxed away and running in a bubble then it's perfect, if however it requires hooks into the system, which is the current paradigm, then they can't cover all cases. What if you have a custom bash profile and it kills it? Or some mix of packages throws a curve ball? At the end of the day you should know your system and requirements more than a faraway team, which reduces the risk.

As someone who has just begun to learn to program (I finished JS lessons on Codecademy two weeks ago), I could attest that the Rails installation was quite daunting. Had I read about the "straight-forward" path you mentioned back then, I'd have just seen "Get acronym > which version of Ruby > What is a gem > Rails > what the hell is fork ".The last thing I want when trying out a new language is to be presented a smorgasbord of options that showcases language's capabilities, but all of which I have little understanding of.

I see this process somewhat analogous to learning a new musical instrument, like a violin. A professional violinist may care to customize many aspects of the instrument to meet his or her needs, including the turning of the instrument (perhaps he cares to set A to 416 to emulate Baroque turning). A beginner, by contrast, would just like to be handed a well tuned instrument ready to learn and experiment. Now, would it kill that beginner to set and tune his own set of strings, or maybe given the options to set his violin to Baroque turning as well? Certainly not - though the necessity and benefits of such an exercise would surely be lost on many beginners.

There's many different ways to install Rails and those will always be available whether someone creates an installer or not as long as source code is available. However, there is a combination of Ruby, Rails, and the database choices that serve as its backend which are common for the "Make a new Rails app and ship to Heroku" workflow that should be easier for being so popular.

I'm really surprised Rails isn't just another component in the Heroku toolbelt. The default Ruby version in OS X is always outdated, the database preferred by Heroku (postgres) is also outdated in OS X, and getting the latest XCode or re-installing it to install brew to install postgres and changing the order of execution in the PATH to make sure it picks up the right version is a prescription for despair and angst. RVM only solves the Ruby and gem versioning problem.

>You are installing something that by it's nature requires a bit more understanding that just clicking on a .exe.

I don't think it inherently require anything like that for _installing_.

There is essential complexity (e.g the complexity of developing a RoR app), and accidental, inessential, complexity.

Installation not being a one click / command process is inessential complexity. It's just that the people involved (and the people NOT involved) have failed to make it any better.

For example, one can install Apache/PHP/MySQL on a Mac in a single package in 1 minute (via MAMP).

The php interpreter isn't used by system processes. I'm not sure how essential the stock Ruby interpreter, but I know that on Linux the system Perl & Python interpreters are used by system processes and upgrading them could potentially break things.

OS X Server uses both PHP and Ruby. From my Lion Server:

    jtm@vertex ~ $ find /usr/share -iname *.php | wc -l
         165
    jtm@vertex ~ $ find /usr/share -iname *.rb | wc -l
        5855

Even if you don't use OS X Server, Ruby.framework has been part of the API since Leopard [1], so applications can (and do) depend on it.

[1] https://developer.apple.com/library/mac/#documentation/MacOS...

  > [...] accidental, inessential, complexity [...]

Sure, but when that complexity is so utterly minuscule, what's the point in shielding users from it? Especially when you could argue that it benefits the user who will, at the very least, roughly know what's powering his application?