21–30 of 39 posts
What about performance and scalability? Doesn't python (with psyco and soon, unladen swallow) win big here? When you choose a platform, it's important to choose one that won't limit you when you start having users on a large scale...
The minus I encountered with Django is that it isn't as far along with the nice auxiliary pieces that exist alongside Rails. Gems are much better than easy_install or eggs. Phusion passenger is easier to deal with than... whatever Django is doing these days. Capistrano is better than Fabric. Heroku is better than App Engine.
What I liked about Django is that integrating other Python libs was easy, and some of them are way better than the Ruby equivalents. PIL is way better than any of the Ruby image manipulation libraries. Django also makes it easier to do GIS stuff out of the box.
In my experience the REAL problem with rails is that if you're actually doing high-load transactional sites, like serious e-commerce systems, it is not up for the task. The successful Rails sites I built mostly had few inserts and a lot of reads. Tons of transactions == meltdown in ways neither I nor professional rails consultants understood. Those pieces were ultimately re-architected in Java (with some JRuby to help out). I'm not convinced Django would help with a site like this.
- 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 mature as pluggables.
Earlier quoted context omitted.
No offence, but why is evaluating technologies which you are going to be stuck with for a very long time a bad thing?
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…
I don't disagree, but I think I should point out the danger -- this is exactly how programmers become dinosaurs in the industry.
Next time you feel the urge to make fun of that guy with 20 years of C++ experience, keep in mind that he was probably just working in a framework that he already understood. One day you look up from your last successful project, and everyone is 22 years old and coding in Blub. Only those old guys are working with Rails....
Stick with rails and don't make the silliest mistake of your life.
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…
What does this mean?
What about performance and scalability? Doesn't python (with psyco and soon, unladen swallow) win big here? When you choose a platform, it's important to choose one that won't limit you when you start having users on a large scale...
Unless something changed, django doesn't even run on psyco cleanly and the combo is unsuitable for production. Unladen swallow also isn't ready for use in production with django and it's unclear when it will be. But performance from these languages aren't the bottlenecks in web apps, and Ruby 1.9 and Python 3 have similar performance, anyway.
That's immaterial in this debate, isn't it? Django doesn't run on Python 3, and Python 3 is still slower than Python 2 (though they're starting to focus on performance improvements in Python 3 with every new release).
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…
And django.
1: Build out your killer idea 2: Learn Django and use it
I don't think the transition from Ror to Django should be that big of a deal for you. Ruby and Python are similar enough, and the frameworks have enough conceptual overlap that it shouldn't be that big of a deal for you to switch.
The Django community is very responsive and professional with questions. Posts on the newsgroup usually get answered within hours, and IRC channel within minutes.
If you do go Django, may I suggest Practical Django Projects: http://www.amazon.com/Practical-Django-Projects-Second-Benne...
Also, if you're looking for off shore Django developers, look up a few people on djangopeople.net.
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…