Ask HN: RubyOnRails or Django/Pylons?
15 comments
Python will be more useful if you decide to do something with the language other than ruby on rails. People do all sorts of very powerful math with it as well (SPSS, SciPy, NumPy and various other things).
ROR is NOT for those who are willing to just get it done. You have to be the type who's willing to find the right way, or risk things blowing all to hell on you (Off the rails, as they call it).
I'd also say, the devs you hire between the two schools seem different. Can't explain it. Django seems to win it for me, both on a scalability ease and learning curve.
(I work with both as backends pretty daily, iOS developer).
Ruby feels cooler, but IMO, python lets you go home and see your kids faster.
ROR is NOT for those who are willing to just get it done. You have to be the type who's willing to find the right way, or risk things blowing all to hell on you (Off the rails, as they call it).
I'd also say, the devs you hire between the two schools seem different. Can't explain it. Django seems to win it for me, both on a scalability ease and learning curve.
(I work with both as backends pretty daily, iOS developer).
Ruby feels cooler, but IMO, python lets you go home and see your kids faster.
I don't object to the "find the right way" comment, with one clarification: he's talking about the web framework.
Ruby is just fine for "just wanting to get it done"; we've used it to write an assembler that models opcodes as Ruby objects, a binary format description language, 3 different debuggers, a web proxy, a hex editor, a whole slew of crypto, a testing framework for the FIX trading protocol, Cocoa UIs, and god-knows-what-else. If you looked at any two of those packages, they might not appear to be written in the same language, let alone the same team.
Rails does not care what crazy Ruby stuff you have built for your specific problem domain. If you are doing graph-theoretic modeling with a custom Ruby library, Rails does not care and it will work fine.
But. If you have even the slightest difference of opinion with Rails as to how to handle a request or represent the URL parameters you're getting from browsers, you're in for a world of hurt. The things Rails has opinions about, it has strong opinions about. And it's a total passive-aggressive asshole about those opinions. It doesn't say no. It slowly punishes you instead. In particular, even though Rails 3 advertises that it has swappable ORMs, you'd be crazy to consider anything but ActiveRecord.
The nice thing about losing degrees of freedom is that you don't have to make decisions about them, so I tend to reject the idea that Python gets you home to your kids faster.
Ruby is just fine for "just wanting to get it done"; we've used it to write an assembler that models opcodes as Ruby objects, a binary format description language, 3 different debuggers, a web proxy, a hex editor, a whole slew of crypto, a testing framework for the FIX trading protocol, Cocoa UIs, and god-knows-what-else. If you looked at any two of those packages, they might not appear to be written in the same language, let alone the same team.
Rails does not care what crazy Ruby stuff you have built for your specific problem domain. If you are doing graph-theoretic modeling with a custom Ruby library, Rails does not care and it will work fine.
But. If you have even the slightest difference of opinion with Rails as to how to handle a request or represent the URL parameters you're getting from browsers, you're in for a world of hurt. The things Rails has opinions about, it has strong opinions about. And it's a total passive-aggressive asshole about those opinions. It doesn't say no. It slowly punishes you instead. In particular, even though Rails 3 advertises that it has swappable ORMs, you'd be crazy to consider anything but ActiveRecord.
The nice thing about losing degrees of freedom is that you don't have to make decisions about them, so I tend to reject the idea that Python gets you home to your kids faster.
An example from recent experience: if you want your application to have multiple cache stores, God help you. I use cache stores to wrap NoSQL stuff in a consistent API that I'm familiar with, and since sometimes I want stuff to be retained indefinitely and sometimes I just need a memcached scratchpad, I have multiple ones. That has gone fine... until it didn't, in a very catastrophic fashion.
What I really, really should have done was write a thin wrapper over the existing Redis code implementing the three methods I typically need my cache stores to support (read, write, fetch -- that's it), then configured the cache stores on class load from a YAML file. This would have gotten me done in an hour.
Instead I tried spelunking deep into the dark recesses of Rails 2.3.10, how it loads environments and initializers, and two gems to figure out what was going on... and very nearly had to postpone shipping because of it.
Don't do that.
But when I'm doing things the Rails Way, yeah, pretty much peaches and cream. I've never had an issue with writing arbitrarily complex Ruby code to do things that are not in the "typical web application" purview.
What I really, really should have done was write a thin wrapper over the existing Redis code implementing the three methods I typically need my cache stores to support (read, write, fetch -- that's it), then configured the cache stores on class load from a YAML file. This would have gotten me done in an hour.
Instead I tried spelunking deep into the dark recesses of Rails 2.3.10, how it loads environments and initializers, and two gems to figure out what was going on... and very nearly had to postpone shipping because of it.
Don't do that.
But when I'm doing things the Rails Way, yeah, pretty much peaches and cream. I've never had an issue with writing arbitrarily complex Ruby code to do things that are not in the "typical web application" purview.
>Ruby is just fine for "just wanting to get it done"
Yeah, I explicitly said ROR there because its the web framework which is annoying when you want to ship. I think the language is pretty neat actually, 'cept doesn't have as many libs.
>But. If you have even the slightest difference of opinion with Rails as to how to handle a request or represent the URL parameters you're getting from browsers, you're in for a world of hurt.
Yeah, sometimes that "way rails thinks you should" is considerably more complicated than what you'd have to do on a PHP or Djagno project to just get that last mile in. I'm currently finishing up a iOS SDK/library that talks to both a rails and django backend, and while the ROR dev is more available, he often has to figure out the right ways to change things that the Django guy just splats out if he has to(and cleans up after we're integrated). The ROR solutions are often frustratingly complicated (want to add a field to this view? Naw you can't, we have to instead change the datamodel of that object and sorry we can't name this that thing you already put in the client, etc). We don't care about long term whatever this week. We just want a certain URL scheme and certain output to happen NOW so we can integrate the last couple chunks in before our announced press event hits us, then backfill with quality code at that URL later. It might just be I know the ruby dev better, but he seems he's probably the better programmer of the two as well (but I don't know the Django guy well).
Sure the rails methodology might be better if you are the type of the person who doesn't do things the right way when you're not forced to , but if you are the type who does things correctly, the Django is no more correct or less correct and canonical, except for those instances when where you just have to finish. So if we're adults, we can write good code most of the time and good enough code when we have to and get away with it on Django. On rails, yeah right. There was a Plone developer who said something once like "Python believes we're all consenting adults". I feel python web frameworks do, and ROR doesn't. (link to the AWESOME talk:http://www.archive.org/details/SeanKellyRecoveryfromAddictio...)
If I wanted bureaucracy, I'd go do a java serverlet. Rails feels more like religious doctrine enforced in code than bureaucracy, but it has that stink of java's "thou shalt use the X to do the Y or DEATH AND INFAMY will result". It's not an overwhelming stick mind you, but a slight odor.
Ruby on Rails DOES work. It just is frustrating in that it does not allow shortcuts, ever. Therefore, I feel it keeps you away from your kids before a commitment, where Django doesn't. I'm not saying "don't ever use it", and I dont' think people who KNOW rails will get enough out of swapping to do the swap, but if you know neither now, I'd go python/django.
Then again, if you're new to programming, the copious beware/here be dragons of ROR might be a better path to get used to not slacking.
Yeah, I explicitly said ROR there because its the web framework which is annoying when you want to ship. I think the language is pretty neat actually, 'cept doesn't have as many libs.
>But. If you have even the slightest difference of opinion with Rails as to how to handle a request or represent the URL parameters you're getting from browsers, you're in for a world of hurt.
Yeah, sometimes that "way rails thinks you should" is considerably more complicated than what you'd have to do on a PHP or Djagno project to just get that last mile in. I'm currently finishing up a iOS SDK/library that talks to both a rails and django backend, and while the ROR dev is more available, he often has to figure out the right ways to change things that the Django guy just splats out if he has to(and cleans up after we're integrated). The ROR solutions are often frustratingly complicated (want to add a field to this view? Naw you can't, we have to instead change the datamodel of that object and sorry we can't name this that thing you already put in the client, etc). We don't care about long term whatever this week. We just want a certain URL scheme and certain output to happen NOW so we can integrate the last couple chunks in before our announced press event hits us, then backfill with quality code at that URL later. It might just be I know the ruby dev better, but he seems he's probably the better programmer of the two as well (but I don't know the Django guy well).
Sure the rails methodology might be better if you are the type of the person who doesn't do things the right way when you're not forced to , but if you are the type who does things correctly, the Django is no more correct or less correct and canonical, except for those instances when where you just have to finish. So if we're adults, we can write good code most of the time and good enough code when we have to and get away with it on Django. On rails, yeah right. There was a Plone developer who said something once like "Python believes we're all consenting adults". I feel python web frameworks do, and ROR doesn't. (link to the AWESOME talk:http://www.archive.org/details/SeanKellyRecoveryfromAddictio...)
If I wanted bureaucracy, I'd go do a java serverlet. Rails feels more like religious doctrine enforced in code than bureaucracy, but it has that stink of java's "thou shalt use the X to do the Y or DEATH AND INFAMY will result". It's not an overwhelming stick mind you, but a slight odor.
Ruby on Rails DOES work. It just is frustrating in that it does not allow shortcuts, ever. Therefore, I feel it keeps you away from your kids before a commitment, where Django doesn't. I'm not saying "don't ever use it", and I dont' think people who KNOW rails will get enough out of swapping to do the swap, but if you know neither now, I'd go python/django.
Then again, if you're new to programming, the copious beware/here be dragons of ROR might be a better path to get used to not slacking.
I thought the same thing after living with Rails in a shipping product for 2 years or so. We embraced Sinatra, which does away with all of your Rails concerns. Sinatra is still very popular; probably the most popular framework after Rails.
However, for my last several projects, I've been back in Rails and happy to be there. Once you understand why things work the way they do in Rails and stop trying to bend it to your own design, it turns out that they mostly got it right. It is, for instance, so much easier to code up preauth/postauth pages in Rails, or to implement permissioning.
However, for my last several projects, I've been back in Rails and happy to be there. Once you understand why things work the way they do in Rails and stop trying to bend it to your own design, it turns out that they mostly got it right. It is, for instance, so much easier to code up preauth/postauth pages in Rails, or to implement permissioning.
I looked into Sinatra, entirely at Thomas' suggestion. My experience after coding up a toy web application was that, if I wanted to build a non-toy application, I'd end up building a half-complete, undocumented, poorly tested version of Rails 1.0 prior to actually being able to work on the stuff people pay me money for.
It is a wonderful microframework if you want to either a) build a web framework because you want experience doing it or b) have some huge honking system which you just want to drizzle a bit of glue code onto and expose pretty much unmodified to HTTP.
It is a wonderful microframework if you want to either a) build a web framework because you want experience doing it or b) have some huge honking system which you just want to drizzle a bit of glue code onto and expose pretty much unmodified to HTTP.
Have you looked at Padrino? I recently experimented with it and was surprised that it was an extremely awesome middle ground, to the point where I'll probably use it for my next project. It's very fast, close to Rack and easy to use with Rack middleware, has Rails-style view helpers, has sinatra-style controllers, very simple and elegant mountable apps, a focus on DB agnosticism, among many other things
Question: Have you experience with it on heroku? Does it work well there? Any difference between its behavior and the "normal case" of RoR as far as what heroku is designed for to your knowledge?
(Like I've said, got nothing about ruby, just don't feel rails is a good fit for the stuff I do; something lighter weight like this could be a good substitue on heroku).
(Like I've said, got nothing about ruby, just don't feel rails is a good fit for the stuff I do; something lighter weight like this could be a good substitue on heroku).
I haven't, but I know it works fine. Heroku is more of a Rack host than a Rails host, so any Rack-based framework (AFAIK, all Ruby frameworks at this point) run seamlessly on it.
Amusingly, I don't recommend Django even for first timers like the guy, however I'm not usually one of those people who answers a different question when asked, for the same sorts of criticisms in some areas as I have about rails. I like itty bitty frameworks usually. Sintra runs on Heroku, and will definitely be brought up before I hear about another project about to be backended there.
Honestly, I think Rails will give you a cleaner project with most groups of devs. There is a lot to be said for that. I think if you took a lot of people who are successful as rails devs, they'd struggle with the "having your own opinions are necessary" issues you have when you hit the open country of python webdev, and not perform as well. If the guy asking is just wanting to make something, I think RoR is a better material, cept it can't do some things. I think Django is a less good "base material" which many people will make an inferior product, but if you're highly competent, it's softer, less rigid structure allows you to be a better rapid developer rapidly dealing with changes to environment and project spec.
I, particularly speaking, happen to be a rapid developer of pretty complex systems. A long rails project is probably going to be a better system, and is almost DEFINITELY going to be a better hand me down from someone else, but a Django system will almost always allow a small change.
Rails is building a house of granite with no other materials. Django is using a bunch of softer stuff.
Honestly, I think Rails will give you a cleaner project with most groups of devs. There is a lot to be said for that. I think if you took a lot of people who are successful as rails devs, they'd struggle with the "having your own opinions are necessary" issues you have when you hit the open country of python webdev, and not perform as well. If the guy asking is just wanting to make something, I think RoR is a better material, cept it can't do some things. I think Django is a less good "base material" which many people will make an inferior product, but if you're highly competent, it's softer, less rigid structure allows you to be a better rapid developer rapidly dealing with changes to environment and project spec.
I, particularly speaking, happen to be a rapid developer of pretty complex systems. A long rails project is probably going to be a better system, and is almost DEFINITELY going to be a better hand me down from someone else, but a Django system will almost always allow a small change.
Rails is building a house of granite with no other materials. Django is using a bunch of softer stuff.
[deleted]
Are you trying to troll? ROR doesn't have a 'right way' it's far from that rails 3 has switchable ORM's, template engines.. etc. Ruby was inspired/designed with elements from perl which itself was designed as a rapid scripting language, your arguments are badly biased.
They're opinionated, not biased. Bias would imply there was something impartial asked for.
Know what else is opinionated? Ruby on Rails. (This is quoted widely on the web, by Rails devs!)[http://www.google.com/search?sourceid=chrome&ie=UTF-8...]
I'm not criticizing ruby, I don't have any issue with it (I'd still go python over ruby, cause I'll take libraries over pretty close but slightly better syntax any day). But ROR can get in your way when it's times to ship as I've explained several times in this thread. Its opinions get in your way when you want to do something it thinks is bad. This is an issue when you want to get work done sometimes.
I don't think the guy is damned to hell if he uses ROR or anything, I just think unless he's a guy who can't make himself (or his teammates) follow the rules when he doesn't have to, he has a stronger product more adaptable to development realities with Django.
Know what else is opinionated? Ruby on Rails. (This is quoted widely on the web, by Rails devs!)[http://www.google.com/search?sourceid=chrome&ie=UTF-8...]
I'm not criticizing ruby, I don't have any issue with it (I'd still go python over ruby, cause I'll take libraries over pretty close but slightly better syntax any day). But ROR can get in your way when it's times to ship as I've explained several times in this thread. Its opinions get in your way when you want to do something it thinks is bad. This is an issue when you want to get work done sometimes.
I don't think the guy is damned to hell if he uses ROR or anything, I just think unless he's a guy who can't make himself (or his teammates) follow the rules when he doesn't have to, he has a stronger product more adaptable to development realities with Django.
How is Django not dramatically more opinionated? It is, we all know it and we know that it's a virtue in that it produces consistent, readable code code. Why are you trying to pretend otherwise?
With Django, there's a whole philosophy behind the right way to do templates. There's a whole explicitly written philosophy behind the specific coding conventions. Whole sections of the framework still assume you are using SQL, ideally Postgres.
Meanwhile, Rails 3 doesn't just support, it increasingly encourages doing things however you want to. Not only that, the community accepts it. Try to use anything but Django templates in your Django project and you'll likely get strong resistence from others on your team or someone who picks up the project after you.
In general, there are far more situations when using Python for web development where I'm pining for a Ruby library than vice-versa. Thankfully some, like Sass and Chef, don't require that the project itself is in Ruby.
With Django, there's a whole philosophy behind the right way to do templates. There's a whole explicitly written philosophy behind the specific coding conventions. Whole sections of the framework still assume you are using SQL, ideally Postgres.
Meanwhile, Rails 3 doesn't just support, it increasingly encourages doing things however you want to. Not only that, the community accepts it. Try to use anything but Django templates in your Django project and you'll likely get strong resistence from others on your team or someone who picks up the project after you.
I'd still go python over ruby, cause I'll take libraries
In general, there are far more situations when using Python for web development where I'm pining for a Ruby library than vice-versa. Thankfully some, like Sass and Chef, don't require that the project itself is in Ruby.
What happens when you do a django template "your way" or "they way we can do it in 2 hours instead of 12"? What happens with the same thing in a Rails project?
People may dislike that you did it, but you still CAN. That's the difference. With Ruby on Rails, you can't necessarily due it without the wheels coming off.
>I'd still go python over ruby, cause I'll take libraries
This is a comment about the non-web components of the language.
>how is Django not dramatically more opinionated?
The Django community is perhaps more opinionated. The actual software isn't. That's the issue with Rails. The actual software has strong opinions (aka, intentional inflexibility) baked into it. I honestly wouldn't pick Django either (preferring even less strict frameworks), but the OP asked a question X or Y, and I told him of those two I feel is better.
People may dislike that you did it, but you still CAN. That's the difference. With Ruby on Rails, you can't necessarily due it without the wheels coming off.
>I'd still go python over ruby, cause I'll take libraries
This is a comment about the non-web components of the language.
>how is Django not dramatically more opinionated?
The Django community is perhaps more opinionated. The actual software isn't. That's the issue with Rails. The actual software has strong opinions (aka, intentional inflexibility) baked into it. I honestly wouldn't pick Django either (preferring even less strict frameworks), but the OP asked a question X or Y, and I told him of those two I feel is better.
What happens when you do a django template "your way"
or "they way we can do it in 2 hours instead of 12"?
This is a comment about the non-web components of the
language.
The Django community is perhaps more opinionated. The
actual software isn't.
The actual software has strong opinions (aka,
intentional inflexibility)
>Depends on what you mean by the software. The framework overall is very opinionated, even if you can use parts of it in a modular way.
Also, Django is WSGI. WSGI is very easy to add layers to to get the job done. (Side note, does everyone pronounce that Wizz Gee in your part of town? They sure as hell do in Atlanta and it slightly confuses me every time I hear it in conversation but can't figure out they're saying WSGI).
Also, Django is WSGI. WSGI is very easy to add layers to to get the job done. (Side note, does everyone pronounce that Wizz Gee in your part of town? They sure as hell do in Atlanta and it slightly confuses me every time I hear it in conversation but can't figure out they're saying WSGI).
You're thinking web apps. Think "apps that have some views which are to the web, but most data feeds for other services" and you'll be in the zone were in. Json and Xml feeds and the like.
ROR is NOT for those who are willing to just get it done. What does that even mean?
I work full time as a Rails developer, and I'd love to give a counterpoint to your obvious distate for Rails, but I have no idea what you're even trying to say....
I work full time as a Rails developer, and I'd love to give a counterpoint to your obvious distate for Rails, but I have no idea what you're even trying to say....
Okay, let me give you the real live example. I build integrated products (mobile app which talks to a few web apps and maybe a desktop app in there too). I'm not a web developer sitting there making a site a human uses a great deal of the time.
You're 9.5 weeks into a 10 week project. Some changes need to be made to a view cause a race condition was found in a load in the client application that talks to your framework.
If you're a rails guy, and you get the feature request, you go "What do I have to change to fix that" <time passes> "Magic happend, it all works". You don't really have the ability always to twiddle the current output in some random way required to just get the comms working with the client and the system incrementally integrated with the world.
If you're the django guy, you go" Let me stick the output you want for now in the view, okay, does that work? cool I'll add some dynamic stuff, Okay cool, does it still work, I'll go do that the right way".
If you work in a position where you sometimes need to do the second one, but largely can behave like an adult and follow the correct ways to do the rest of the time, Django will be more rewarding to you than Rails, as you can get away with building that last mile out of earwax and sticky tack if you want to on Django, but on rails, you really have to used that same deliberate hand carved ivory you used everywhere else.
Which project is going to be purtier when you're done? Rails for sure! Which one is going to be easier to expand off of? Probably rails will take less time to get to the next version, as there will be no cleanup time to take out the sticky tack. Can you hack the crap out of something when you need to pop something out the door for the demo tommorrow? It really really varies upon what the hack is you need to pull. With Django it doesn't. That's the issue. That's what I mean about "willing to just get it done".
By willing to just get it done, I mean take the immediate pre-ship shortcuts and workarounds that you have to do often to ship on time. Rails abhors a shortcut or an abridgment. I think it has very large strengths for a lot of people. But for others, working in certain types of jobs, I find this insistance of "not going off the rails" infuriating.
Yes, I know if you're a ruby god whos' done rails for a very long time, and knows exactly how everything works, you CAN do this sort of thing. I've worked with some of you actually. I think you guys are cool. But the general ROR guy can't. The general Django guy can.
Django is a 18 wheeler truck and Rails a freight train. They do different things well. But damn, you crash if you take that train off the rails, but you can survive offroading in that truck for a bit to make that delivery at a weird stop.
You're 9.5 weeks into a 10 week project. Some changes need to be made to a view cause a race condition was found in a load in the client application that talks to your framework.
If you're a rails guy, and you get the feature request, you go "What do I have to change to fix that" <time passes> "Magic happend, it all works". You don't really have the ability always to twiddle the current output in some random way required to just get the comms working with the client and the system incrementally integrated with the world.
If you're the django guy, you go" Let me stick the output you want for now in the view, okay, does that work? cool I'll add some dynamic stuff, Okay cool, does it still work, I'll go do that the right way".
If you work in a position where you sometimes need to do the second one, but largely can behave like an adult and follow the correct ways to do the rest of the time, Django will be more rewarding to you than Rails, as you can get away with building that last mile out of earwax and sticky tack if you want to on Django, but on rails, you really have to used that same deliberate hand carved ivory you used everywhere else.
Which project is going to be purtier when you're done? Rails for sure! Which one is going to be easier to expand off of? Probably rails will take less time to get to the next version, as there will be no cleanup time to take out the sticky tack. Can you hack the crap out of something when you need to pop something out the door for the demo tommorrow? It really really varies upon what the hack is you need to pull. With Django it doesn't. That's the issue. That's what I mean about "willing to just get it done".
By willing to just get it done, I mean take the immediate pre-ship shortcuts and workarounds that you have to do often to ship on time. Rails abhors a shortcut or an abridgment. I think it has very large strengths for a lot of people. But for others, working in certain types of jobs, I find this insistance of "not going off the rails" infuriating.
Yes, I know if you're a ruby god whos' done rails for a very long time, and knows exactly how everything works, you CAN do this sort of thing. I've worked with some of you actually. I think you guys are cool. But the general ROR guy can't. The general Django guy can.
Django is a 18 wheeler truck and Rails a freight train. They do different things well. But damn, you crash if you take that train off the rails, but you can survive offroading in that truck for a bit to make that delivery at a weird stop.
>> I'd also say, the devs you hire between the two schools seem different. Can't explain it. Django seems to win it for me, both on a scalability ease and learning curve.
Interesting observation... I find that the culture of Rails developers is less to my taste than among Django developers. I can't explain it either, maybe it's personal preference for Django culture or maybe it's something more fundamental like Django devs are less insecure about their platform. I dunno either.
Interesting observation... I find that the culture of Rails developers is less to my taste than among Django developers. I can't explain it either, maybe it's personal preference for Django culture or maybe it's something more fundamental like Django devs are less insecure about their platform. I dunno either.
Python will be more useful if you decide to do
something with the language other than ruby on rails
with it as well (SPSS, SciPy, NumPy and various other
things)
Rails 3 is such a major improvement that I recommend it highly. The new modularity is enabling all kinds of interesting developments, like nesting apps within apps, authentications among multiple frameworks, and speed improvements.
Ruby 1.9.2 is also a major improvement in speed, and JRuby is icing on the cake especially for large scale projects, integration with legacy code, and detailed debugging.
Ruby 1.9.2 is also a major improvement in speed, and JRuby is icing on the cake especially for large scale projects, integration with legacy code, and detailed debugging.
You have a week of Python. Spend 2 days with Ruby. If you fall in love with Ruby, go with Rails. Otherwise, stick to Python. It's that simple. They're basically the same thing.
The differences between python and ruby aren't the important thing in this question. The languages are different (ruby: better syntax, python: better libraries). The important thing is "Are you the type of person who will excel with very strong strictures on your work" (Do rails) or "Are you a person who sometimes disregards the rules to do work more expeditiously" (Do python)
You have that completely backwards. If you are coding your Python like that, you are doing it wrong and almost certainly drawing the ire of the people you work with.
I mean, they get really pissed off when we hack a view 2 days before a deadline instead of just not delivering it. I mean people LOVE when you don't deliver.
Hacks are not good. Hacks should not be done all the time. But sometimes, shipping is more important than beauty and elegance. Hacks you put up while you get the real, good code in place is next to godliness when working in multicomponent systems under tight deadlines. Rails just isn't as good when you need to do that sort of thing. It doesn't have that flexibility, by design!
When I write the hacked up glue code first so they can do their stuff while I write mine, they f-ing love that. It lets them do their job!
I do things "the right way" 99% of the time. That buys me incredible flexibility to use utter crap code that's otherwise functional that other 1% of the time when required by the job.
Hacks are not good. Hacks should not be done all the time. But sometimes, shipping is more important than beauty and elegance. Hacks you put up while you get the real, good code in place is next to godliness when working in multicomponent systems under tight deadlines. Rails just isn't as good when you need to do that sort of thing. It doesn't have that flexibility, by design!
When I write the hacked up glue code first so they can do their stuff while I write mine, they f-ing love that. It lets them do their job!
I do things "the right way" 99% of the time. That buys me incredible flexibility to use utter crap code that's otherwise functional that other 1% of the time when required by the job.
I don't presume to know your work environment, but personally I work on my own projects and do contract work and, in my experience, taking on debt is usually a sign that there's a problem with the requirements and estimates, so I usually change those before making the code less maintainable (which, IMO, is usually a case of treating the symptom).
Regardless, I'm weary of claims that controller-level (django view level) code is a major pain point in Rails. In some ways it's actually easier since you can make fewer decisions by making them resource centric, but even deviating from that is as simple as map "/path", :to => "controller#action".
Rails/Django controllers/view and routing/urls aren't as elegant as micro-frameworks like Flask and Sinatra or not-so-micro-frameworks like Padrino, but they aren't anything close to serious stumbling blocks (though maybe routing to a very small degree in resource-centric Rails 2). Every blocking issue I've had with either framework has been on a deeper level. In Rails pre-3, it was usually configuration-related when trying to do something too unconventional. In Django, it's when trying to deviate from the overall Django philosophy and use something other than the included batteries.
Regardless, I'm weary of claims that controller-level (django view level) code is a major pain point in Rails. In some ways it's actually easier since you can make fewer decisions by making them resource centric, but even deviating from that is as simple as map "/path", :to => "controller#action".
Rails/Django controllers/view and routing/urls aren't as elegant as micro-frameworks like Flask and Sinatra or not-so-micro-frameworks like Padrino, but they aren't anything close to serious stumbling blocks (though maybe routing to a very small degree in resource-centric Rails 2). Every blocking issue I've had with either framework has been on a deeper level. In Rails pre-3, it was usually configuration-related when trying to do something too unconventional. In Django, it's when trying to deviate from the overall Django philosophy and use something other than the included batteries.
I'm not arguing for systemic mortgages worth of debt. I'm arguing for using your credit card occasionally cause its easier than constantly going to the cash machine.
Use case:
iPhone dev "can you do this"
Ruby dev "Sure, takes a sec to rejigger things to allow that"
A few minutes/hours later "Done, and its perfect"
Alternative
iPhone dev "can you do this slightly differently"
Django dev "Like that?" [Just mocked up the entire thing in pure text, django happily returns it]
iPhone dev "thanks"
Django dev "I'll go make that work right now now that you can integrate your code
I have a real problem with the inability to provide a good enough version now when its more valuable than a very good version later, especially when there is room in the schedule to deliver both.
I work in an integration based environment, where the turnaround on the backend development is the maximum schedule issue, not the overall development scheme. I don't want my software development effort to look like the execution of a python program in a GIL bound multiprocessor environment. I want the thing done asap, if that means I'm paying the backend guy to redo his code 3 times cause the prototype is valuable and speeds up final time, I want the flexibility to do that.
I'm Excited that rails 3 promises to help part of this (as you correctly surmised, it is mostly rails 2 code and coders and turnaround issues I've dealt with), but I haven't yet seen it very much yet at all.
Schedules, requirements and all that are great, but if you can put a little hustle in at the end when there is something big on the line and get paid for that, you have very happy customers and very fat wallets. Non software people like delivery and there is a modicum of debt that sometimes requires.
Use case:
iPhone dev "can you do this"
Ruby dev "Sure, takes a sec to rejigger things to allow that"
A few minutes/hours later "Done, and its perfect"
Alternative
iPhone dev "can you do this slightly differently"
Django dev "Like that?" [Just mocked up the entire thing in pure text, django happily returns it]
iPhone dev "thanks"
Django dev "I'll go make that work right now now that you can integrate your code
I have a real problem with the inability to provide a good enough version now when its more valuable than a very good version later, especially when there is room in the schedule to deliver both.
I work in an integration based environment, where the turnaround on the backend development is the maximum schedule issue, not the overall development scheme. I don't want my software development effort to look like the execution of a python program in a GIL bound multiprocessor environment. I want the thing done asap, if that means I'm paying the backend guy to redo his code 3 times cause the prototype is valuable and speeds up final time, I want the flexibility to do that.
I'm Excited that rails 3 promises to help part of this (as you correctly surmised, it is mostly rails 2 code and coders and turnaround issues I've dealt with), but I haven't yet seen it very much yet at all.
Schedules, requirements and all that are great, but if you can put a little hustle in at the end when there is something big on the line and get paid for that, you have very happy customers and very fat wallets. Non software people like delivery and there is a modicum of debt that sometimes requires.
You won't get a non-biased answer here. Both of them are good and similar. If you are looking for something different, give node.js+express.js a try, it's good too though a bit less mature.
(Opinion warning, as in "this works for me", not an absolute truth)
I like Rails better because:
* I like Ruby more than Python (no "self" in methods, Ruby's list.map(func) vs Python's map(list, func), usable as a template language (ERB), open classes -> easy hacking)
* Rails `Books#has_one :publisher` vs Django `models.ForeignKey(Publisher)`
* Rails migrations + db reflection vs Django attr declarations `models.CharField(max_length=300)` (Yes I know about south, you still declare the attrs tough)
* Rails has Bundler http://gembundler.com/ , dunno about Py ...
* Django router http://docs.djangoproject.com/en/1.2/topics/http/urls/ vs Rails router http://guides.rubyonrails.org/routing.html (ie. declarative regexps vs executable well tought semantics)
* rails erb (haml etc) views vs django's-template-language because python can't do templates because of the indenting
* the list goes on but I'm bored
Ruby is beter at web stuff than Python.
Python has more science stuff (NumPy etc).
So I vote Ruby on Rails
I like Rails better because:
* I like Ruby more than Python (no "self" in methods, Ruby's list.map(func) vs Python's map(list, func), usable as a template language (ERB), open classes -> easy hacking)
* Rails `Books#has_one :publisher` vs Django `models.ForeignKey(Publisher)`
* Rails migrations + db reflection vs Django attr declarations `models.CharField(max_length=300)` (Yes I know about south, you still declare the attrs tough)
* Rails has Bundler http://gembundler.com/ , dunno about Py ...
* Django router http://docs.djangoproject.com/en/1.2/topics/http/urls/ vs Rails router http://guides.rubyonrails.org/routing.html (ie. declarative regexps vs executable well tought semantics)
* rails erb (haml etc) views vs django's-template-language because python can't do templates because of the indenting
* the list goes on but I'm bored
Ruby is beter at web stuff than Python.
Python has more science stuff (NumPy etc).
So I vote Ruby on Rails
the most recent post is more than a year old
And I'm going to refer to my comment from that discussion: http://news.ycombinator.com/item?id=1830895
Sorry for that, seems my GoogleFu is in need of some work.
Write this applications in both languages:
- a url shortener.
- a easy blog system.
- a naive twitter.
Pick whatever feels more natural to you. If you wet stuck in any of this applications, you can drop me a line, I will try to help you.
- a url shortener.
- a easy blog system.
- a naive twitter.
Pick whatever feels more natural to you. If you wet stuck in any of this applications, you can drop me a line, I will try to help you.
Thanks for the great suggestion, and unbiased answer. I think that is the path I'm going to take.
Python vs Ruby - Both are great. I tried ruby first for a week or so and then move to python; I love python simplicity. According to my learning experience you can learn python faster then any other language (I am a ASP.NET/C# developer in my day job.)
Django vs Rails - I don't have any experience with Rails because you must know ruby first. Django is a natural choice for me because of python. Till now it seems good to me (around a month experience). It is seem not so cool in comparison to Rails but its good (I also know little bit of ASP.NET MVC).
Note: I am not an expert in both language/framework, so you can ignore my suggestions.
Django vs Rails - I don't have any experience with Rails because you must know ruby first. Django is a natural choice for me because of python. Till now it seems good to me (around a month experience). It is seem not so cool in comparison to Rails but its good (I also know little bit of ASP.NET MVC).
Note: I am not an expert in both language/framework, so you can ignore my suggestions.
The best way to pick a framework is the same as the best way to pick anything-- make a simple app like a blog or a forum with both frameworks and decide from there which one you like better.
I chose Django because I love working with Python, and it still can provide a lot of value without the framework. Django is also less cumbersome when you first build a project (a handful of files vs multiple directories and files form rails.) Django also provides a lot of useful stuff out of the box -- like an admin interface.
Besides that, everything I've seen built in RoR can be built with Django, and vice-versa. The frameworks and the languages are pretty similar, so it's mostly a matter of taste.
Besides that, everything I've seen built in RoR can be built with Django, and vice-versa. The frameworks and the languages are pretty similar, so it's mostly a matter of taste.
Seconded. It really comes down to whether you like Ruby or Python best.
>I chose Django because I love working with Python, and it still can provide a lot of value without the framework.
Ruby on Rails folks hate when you say that though, cause it makes the language half of their equation look less good. It feels like a "Oh No You're going off topic no fair". They should just say "Yup, python is better for that other stuff" not "But we're talking about webdev!". To me, it agains feels like a community thing. Rails community does stuff like that, Django people seem to care less if you like what they do too.
The fact my rails apps can't as easily control hardware, do math, or call C++ or Objective C code with minimal glue actually is a problem for some solutions I do. So I like python (my actual preferred solution right now is GAE, not Django, but that's more economics/scaling based than technical. To be honest my latest rails dalliance is because of the characteristics of heroku, not rails itself
Ruby on Rails folks hate when you say that though, cause it makes the language half of their equation look less good. It feels like a "Oh No You're going off topic no fair". They should just say "Yup, python is better for that other stuff" not "But we're talking about webdev!". To me, it agains feels like a community thing. Rails community does stuff like that, Django people seem to care less if you like what they do too.
The fact my rails apps can't as easily control hardware, do math, or call C++ or Objective C code with minimal glue actually is a problem for some solutions I do. So I like python (my actual preferred solution right now is GAE, not Django, but that's more economics/scaling based than technical. To be honest my latest rails dalliance is because of the characteristics of heroku, not rails itself
(opinion warning)
ruby is more nice to the programmer. python has more corporate backing. django is a pain-in-the-ass compared to rails, pylons is better but still not the collection of power tools that is rails. i feel the python community is tail chasing the ruby community now-a-days. catching up will be hard as the python language misses the "principle of least supprise" that is a guiding principle for ruby. python (like c++) managed to supprise me after year of coding with it.
ruby is more nice to the programmer. python has more corporate backing. django is a pain-in-the-ass compared to rails, pylons is better but still not the collection of power tools that is rails. i feel the python community is tail chasing the ruby community now-a-days. catching up will be hard as the python language misses the "principle of least supprise" that is a guiding principle for ruby. python (like c++) managed to supprise me after year of coding with it.
:-) More people should use the opinion warning
(Opinion warning) They're basically the same level of overall goodness. Django may be better at some things, Rails on others. The whole penis-size-measuring contest between both camps is kind of annoying actually. Having said that, I REALLY enjoy Django, a lot, and recommend it to everyone when they ask which of the two they should chose.
(Opinion warning) They're basically the same level of overall goodness. Django may be better at some things, Rails on others. The whole penis-size-measuring contest between both camps is kind of annoying actually. Having said that, I REALLY enjoy Django, a lot, and recommend it to everyone when they ask which of the two they should chose.
>(Opinion warning) They're basically the same level of overall goodness. Django may be better at some things, Rails on others.
You try to state that opinion around here, even clearly stating the stuff Rails is better at, but you get railed on when you say the stuff it ain't better at is why you prefer the other. See what happens.
You try to state that opinion around here, even clearly stating the stuff Rails is better at, but you get railed on when you say the stuff it ain't better at is why you prefer the other. See what happens.
As a person who talks with people at corporations about stuff like this (heroku vs gae vs ec2 vs corporate data center is a huge discussion these days in the business community, even for non-consumer facing sites and backends to non-web projects):
They hate 2 features of rails in the conversations I've had: The fact rails devs seem unwilling to take shortcuts that Django/other python webdev guys will. They also hate "It is just broken", which seems to come out of rails guys in their experience more. Note these are entirely non-technical and come from a open ended menu.
Also, my particular town has a pretty large python community (we hosted pyCon in 2010 if you went, I wrote the initial bid).
They hate 2 features of rails in the conversations I've had: The fact rails devs seem unwilling to take shortcuts that Django/other python webdev guys will. They also hate "It is just broken", which seems to come out of rails guys in their experience more. Note these are entirely non-technical and come from a open ended menu.
Also, my particular town has a pretty large python community (we hosted pyCon in 2010 if you went, I wrote the initial bid).
I like the python community better than the ruby one. So I ended up going with python.
That said, I really like Pylons. I wish I could find more people who use it. It is one of those frameworks that gets more powerful and makes things easier as your webapp gets more and more complex. This is opposed to rails or django where if you didn't design it at the get go and try to bolt it on you tend to be fighting the framework.
That said, I really like Pylons. I wish I could find more people who use it. It is one of those frameworks that gets more powerful and makes things easier as your webapp gets more and more complex. This is opposed to rails or django where if you didn't design it at the get go and try to bolt it on you tend to be fighting the framework.
I use rails, I can only comment on pylons and turbogears from around 2006 when I gave up on it. I gave up on both turbogears and pylons due to 1. no community and 2. nearly no updates. Rails has a huge community, lots of plugins, etc as does Ruby. As for Ruby itself the language just meshes with my way of thinking if Python does that for you then go for Django
I'm happy using Ruby and Python and have built sites with Rails and Django in the past. These days I mostly use Flask (sorta like Sinatra in Python) as its lightweight and has templates that don't drive me insane (sorry Django). For a large app with lots of models and mixed developers I would likely choose Rails.
I would personally say Ruby. But then again; given a longer answer I would say the same thing I say about camera brands. Pick both up, which feels 'right' to you?
Ruby and Python are both great languages. I prefer Ruby as I see it as the current front runner.
Ruby and Python are both great languages. I prefer Ruby as I see it as the current front runner.
I'm a fairly experienced developer (Java, C#, Objective-C) and I want to try my luck with some webapps. I've used python for small things, but nothing that you wouldn't learn in a week, so basically, I'm new to python or ruby.
So, assuming I'm already a programmer and want to learn web programming with any of the above, which one would you recommend based on their functionalities and ease of learning?