Live data from Hacker News

Ask HN: Updated recommendation on Rails versus Django?

news.ycombinator.com

31–39 of 39 posts

Re: Ask HN: Updated recommendation on Rails versus Django?

#31
post #24

Earlier quoted context omitted.

"fretting too much about the apparent greenness of the grass on the other side of the fence is always a warning sign of procrastination, doing so when you already have three years of Rails experience and know exactly where its pain points are is really a sign of procrastination. Just build the thing already! You will save time by working in a framework that you already understand." I don't disagree, but I think I sho…

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.

Re: Ask HN: Updated recommendation on Rails versus Django?

#32

Trust me, Django is almost dead. The hype around Django is completely dead and existing developers are using it, but new developers are not jumping on ship. In 6 years there will be a serious Django shortage of maintanance personell. Stick with rails and don't make the silliest mistake of your life.

Any statistics you have to back that up?

Re: Ask HN: Updated recommendation on Rails versus Django?

#33
Either-or is ridiculous. It's a false dichotomy and they're practically the same language. With 11 years of total experience, if you found it impossible to fit Ruby and Python in the same brain, you'd have to be a complete fucking idiot. I understand why newbies a year out of college might consider Ruby vs. Python to be a question at all, but you are not in that position. It's a language. It's good. Go ahead and use it.

Re: Ask HN: Updated recommendation on Rails versus Django?

#34
post #31

Earlier quoted context omitted.

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 sa…

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. :(

Re: Ask HN: Updated recommendation on Rails versus Django?

#35
post #24

Earlier quoted context omitted.

Because, in all likelihood, worrying that you're going to be stuck with your initial choice of technology for a very long time is premature optimization. You should be so lucky. I have no idea what the original submitter's idea is, but I'll still predict how it's going to work out: It won't find product-market fit. So it won't need to be maintained for a very long time. So he might as well just build it with the fram…

"fretting too much about the apparent greenness of the grass on the other side of the fence is always a warning sign of procrastination, doing so when you already have three years of Rails experience and know exactly where its pain points are is really a sign of procrastination. Just build the thing already! You will save time by working in a framework that you already understand." I don't disagree, but I think I sho…

That's why you play around with new technologies in your free time. Then, when it's time to build your next big project, it's not "I have three years experience with X and none with Y; which should I use?" but rather "I have three years experience with X, but I've been playing with Y for the past year and I think it's a better fit."

Re: Ask HN: Updated recommendation on Rails versus Django?

#36
post #35
post #24

Earlier quoted context omitted.

"fretting too much about the apparent greenness of the grass on the other side of the fence is always a warning sign of procrastination, doing so when you already have three years of Rails experience and know exactly where its pain points are is really a sign of procrastination. Just build the thing already! You will save time by working in a framework that you already understand." I don't disagree, but I think I sho…

That's why you play around with new technologies in your free time. Then, when it's time to build your next big project, it's not "I have three years experience with X and none with Y ; which should I use?" but rather "I have three years experience with X , but I've been playing with Y for the past year and I think it's a better fit."

Yes, yes. The problem comes when you don't have much free time. When you're working on a successful project, it will consume every hour that you can devote to it. If you then want to have a life outside of computers, you find yourself having to make a conscious choice between your main project, and learning new technologies.

This problem becomes far more acute as you get older. When I was in college, I had all the time in the world to experiment with things. These days, I don't have much energy for computers when I'm away from work.

Re: Ask HN: Updated recommendation on Rails versus Django?

#37

Here's what I've found so far after starting a small Django gig (I already knew a fair bit about Rails): - Rails has built-in migration support - Rails has better support for APIs - Django has some neat stuff in contrib including authentication and an admin interface - Django has "pluggables" -- downloadable apps that can be snapped in just like the admin interface. Rails has engines, but they're new and not as matur…

> Rails has better support for APIs What does this mean?

Probably talking about ready-built libraries. Poorly worded though.

Re: Ask HN: Updated recommendation on Rails versus Django?

#38

Here's what I've found so far after starting a small Django gig (I already knew a fair bit about Rails): - Rails has built-in migration support - Rails has better support for APIs - Django has some neat stuff in contrib including authentication and an admin interface - Django has "pluggables" -- downloadable apps that can be snapped in just like the admin interface. Rails has engines, but they're new and not as matur…

> Rails has better support for APIs What does this mean?

To be specific, Rails has better support for providing XML and JSON APIs. One place where it has better support is serialization. In rails, there is an :include parameter to control whether to include objects from associations (e. g. comments in a post), that is available both on to_xml or to_json. I don't see an option for Django that does the same thing.

http://api.rubyonrails.org/classes/ActiveRecord/Serializatio... http://docs.djangoproject.com/en/dev/topics/serialization/

Re: Ask HN: Updated recommendation on Rails versus Django?

#39
post #11
post #8

You can't go wrong with any of them. I think Django has a slight edge by having a slower release cycle. I find it a desirable quality in a development framework. While the number of man-months spent developing Rails is an order of magnitude greater than that spent developing Django, is it really that much better for the bottom line? Most of the early efforts spent on Rails were to make the infrastructure and communit…

> While the number of man-months spent developing Rails is an order of magnitude greater than that spent developing Django Wildly off base figure 1. Years under development. ROR: 5/Django 5 2. Members in largest google group: ROR 18000+/Django 14000+ 3. Members in Irc currently: Ror 436/Django 401 4. Commits to repo: Ror ?/Django 11000+ So while Ror has a bigger community, it is not that much bigger.

There is no easy way to measure this. But to support my point:

Rails first public release: July 2004 (5 years back)

Django's first public release: July 2005 (4 years back)

Rails Contributors: 1350

Django Contributors: 460

I never said that Django's community was smaller. I just said that it was more mature in their programming language and therefore it was easier for them to get things done right the first time.

Post reply on HN