> And things like the Rails monolith that GitHub's main service is, have a tendency of being rude to a dev's laptop
FUD. Everything is neatly handled by rvm (or rbenv) and bundler. You can even use gemsets if you want to be really anal about it. It all goes in version-controlled user directories. I keep my main Mac machine, my work Windows machine, and the production Linux boxes all running the same versioned stack just fine.
What do you mean FUD? Maybe you've got your own way of doing things that works well so far for you with your current projects, but a ton of people don't live with the same experience, and when they do reach a comfortable spot, it's only comfortable until they move to a new set of projects or company.
I'm saying that, while a top-tier, software-as-a-service company might have a development environment that is hard to bootstrap -- because of all the ancillary things that run alongside the "monolith" -- your generalization that "Rails" makes a mess of a development machine is FUD. The Ruby/Rails part of this equation is not the issue. As always, YMMV and TACMA.
I didn't say Rails makes a mess of a dev machine. What I'm saying is that every project makes different sort of assumptions about how it's brought up in a dev environment, and these assumptions vary wildly between projects and stacks, and usually the older and more prominent a project is, odds are it will have the most unexpected impact on anyone's machine. This is going to be true for any combination of libraries, frameworks and programming languages.
I'm not mounting an attack on Rails. Rails' fine.
(Edit) I can't answer your reply. It seems there's many ways to read the quote you brought up. I'm clarifying that the meaning I intended wasn't an attack on Rails. Take it as you will. I'm a bit confused why my original comment, which I meant as a positive-to-neutral tone, is being perceived so negatively.
FUD. Everything is neatly handled by rvm (or rbenv) and bundler. You can even use gemsets if you want to be really anal about it. It all goes in version-controlled user directories. I keep my main Mac machine, my work Windows machine, and the production Linux boxes all running the same versioned stack just fine.