I can't argue with this in general, but it hasn't got much to do with the case at hand. Worrying about the day when Rails will be a dinosaur technology is an even more extreme form of premature optimization. And if you are trying to hedge against Rails' obsolescence, why would you pick Django? Shouldn't you pick something sufficiently different that it isn't routinely mentioned in the same sentence?
I'm not worried about it, and I realize it's a digression. I'm just saying that if every time you face one of these decision points you go with the technology that you already know, then you're optimizing for something different than career longevity, and it will come back to bite you. The point is that there's always a tension in this industry between learning new technologies and being maximally productive.
That said, it isn't "premature optimization" to diversify your portfolio of technologies as much as possible. It's premature to try to guess the Next Big Thing and use it for your project, but that isn't what I'm suggesting. And in any case, five(-ish) years ago, you might well have faced the choice between using Perl and using Rails for a similar project. That decision would have proved fateful.
five(-ish) years ago, you might well have faced the choice between using Perl and using Rails for a similar project. That decision would have proved fateful.
Let's keep some perspective here. Rails, Django, and the various Perl frameworks each have their rabid partisans, but they represent fairly tiny variations on a single theme: Client-server web applications. There is very little danger in overspecializing in any one of these. You can move from one to another with ease. They employ similar concepts, by necessity. The HTTP and the SQL and the CSS knowledge all transfer over. The browser is still the browser. My god, I wish the browser was changing fast enough that I risked becoming a dinosaur!
I suspect that there is far more danger of overspecializing in, say, MySQL than of overspecializing in Rails. Databases are huge, complex beasts with real differences in their implementation and operation, and they can have profound impact on the performance of your app. (Just ask an experienced Oracle DBA. He or she will talk your ear off, as happened here on HN the other week.) The difference between the various brands of glue that we use to stick our databases to our web servers? Not as fundamental as we'd all like to think. The stuff I do today is not much different from what I and my colleagues were doing in AolServer Tcl in 1999. (Now that is dinosaur web technology!)
The real danger of becoming a dinosaur happens at a higher level. I'm a professional PHP programmer now, god help me, but I'm not afraid of missing out on the Great Django Revolution: When Django is finally ready to call my colleagues and I, I'll listen, and I'll probably understand what it's saying because it'll still be speaking the language of server-side web apps. The real danger is that one day I'll wake up and realize that the interesting problems have moved off the web server entirely and that all the fun is in standalone Javascript apps, or iPhone apps, or Microsoft Surface 3.x apps, or Scala applications embedded in your shoes, and server-side web app development has become about as exciting as Internal Revenue data processing (which it resembles in many ways).
When I really want to diversify, I'll look at Javascript or Objective C or embedded systems programming. I won't look right next door. That's too easy. Alas, this means that my track record of never getting around to learning Python may continue. :(
