Even though the average engineer may be more productive with modern tools than the average engineer without them, there is danger in assuming that any engineer with modern tools will outperform any engineer with less modern tools. Just like software, tools can be an enabler, but they do not make the engineer a commodity.
I'm still a rather young programmer (only about 6 years into my career). But I've found myself actually working in a reverse flow of technology, in terms of what tools I use on a daily basis to do my job. I'm primarily a Microsoft-stack web applications developer. I spend most of my day writing out c# and t-sql; often, using Visual Studio and MS Management Studio to interact with my code and the database. Those are the tools I used at the start of my career, when really getting the hang of basic programming.
As I've moved forward (career-wise), I now find myself using rather "older" tools for my day to day tasks. I hate to touch a Windows machine without Cygwin installed, as BASH is my primary interaction with the computer now. And I find myself generating code at a faster pace in VIM than I can in VS. As I've started using more Postgres databases, I've grown more comfortable with psql, and the terminal-based interaction with the db.
So the actual tools I'm using to generate my work are, in a sense, "old". I've found myself almost shunning new tools. Or at the very least, not embracing new tools _just_ for the sake of them being new. A new tool has to have some value aside from "newness."
Use of these "old" tools is not to say that my skills as a developer are lagging behind, however. The same even goes for the languages I've been using for personal projects. I find myself working out ideas more quickly in Common Lisp (how's that for old?) than I can in c#.
The point I'm trying to make is: don't focus on whether or not the person is using the newest tools to do the job. What's going to matter more is how well they understand the fundamentals of their discipline. Granted, I'm still young, but I feel like the craftspeople that really understand the core principles of their craft, and keep an eye on the horizons of their craft, are going to remain in demand (so long as the craft is needed). And if that craft is software development, it won't so much matter whether the coder is embracing Rails or not; what will matter is that s/he understands the new ideas that Rails might embody, and can incorporate those ideas into their daily flow.
That line jogged loose a memory that might cause some thought in other so I'll share:
I used be an aerospace engineer. Typically, what we called * designers* were technical people who were very good at working with fancy 3D parametric, version controlled CAD systems. They could come up with mechanical designs and drawings at a rapid pace and good results. They rarely had engineering degrees and leaned a bit on the technical knowledge of the engineers when they needed to.
But we had one guy who refused to learn the new systems and instead insisted on using old, some might say obsolete) 2D CAD that he was familiar with. He happend to have an engineering degree, but most wouldn't guess because 9 out of 10 people picked him out as a dead ringer for Charlie Manson. He was loud, sometimes dirty, dressed more like a biker than an engineer, and he was rude and stubborn. I liked the guy. I really did. But I think I held a rare view, as most people found him offensive and crude. Some refused to work with him. "I'm not changing that" was almost a calling card of his.
Yet in spite of all of that, he designed a frighteningly high percentage of the space hardware that actually flew. His time was in demand and he produced easily as much as the designers with more modern tools. I never counted, but I'd bet he produced more than they did. And it was good because he was brilliantly skilled at the real task at hand.
So in the end, the technology did not matter - the man did.
I don't bring that up to argue- just think there's something worth thinking about.