Ask HN: What should I learn next: Ruby or Python ?
I'm coming from a C/C++/PHP/Javascript background. I'm not sure which to learn between Python and Ruby. Both language are very similar and lately, Ruby seems to get a lot of hype (thanks to Ruby on Rails). However, Python has Django and is the language of choice of Google so it can't be bad ;) Which one would you recommend me to learn ?
9 comments
Either one is fine. They are both dynamic and flexible languages, mature, have powerful web frameworks, and fairly large library repositories.
The choice is more a matter of preference. Python generally encourages you to do "the right thing". Ruby offers more room for doing things the way you like them.
The choice is more a matter of preference. Python generally encourages you to do "the right thing". Ruby offers more room for doing things the way you like them.
Whether you pick Python or Ruby, you should try to avoid diving right into Django or Rails.
Work through Mark Pilgrim's "Dive Into Python" or _why's "Poignant Guide to Ruby".
If you want to write a web app, start with Google AppEngine w/ it's webapp framework, or Heroku w/ Sinatra.
Work through Mark Pilgrim's "Dive Into Python" or _why's "Poignant Guide to Ruby".
If you want to write a web app, start with Google AppEngine w/ it's webapp framework, or Heroku w/ Sinatra.
This! If you are doing Ruby, definitely start with Heroku and Sinatra. It's very simple, clean, and an excellent starting point.
You can move to Rails once you got the basics of Ruby down -- Rails will make a lot more sense then.
You can move to Rails once you got the basics of Ruby down -- Rails will make a lot more sense then.
Things I love about Ruby (I have not used Python yet):
- everything is an object, so you can e.g. store code in a Proc to execute it later or add new methods to Numbers (e.g. 1.kilobyte => 1024)
- very clean syntax and expressive method names means you don't need to document much, it's pretty obvious most of the time (e.g. 3.times do print "ho" * 3 end => "hohoho")
- very flexible, allows nice DSLs that read a lot like english (e.g. Rails or RSpec)
- interesting community with lots of free material (e.g. _why's poignant guide, railscasts.com, therubyshow.com, ...)
I'm sure Python is pretty cool as well, but from all I've heard (I had the same question a while ago) Ruby seems to fit me better with its "more fun and freedom" philosophy.
- everything is an object, so you can e.g. store code in a Proc to execute it later or add new methods to Numbers (e.g. 1.kilobyte => 1024)
- very clean syntax and expressive method names means you don't need to document much, it's pretty obvious most of the time (e.g. 3.times do print "ho" * 3 end => "hohoho")
- very flexible, allows nice DSLs that read a lot like english (e.g. Rails or RSpec)
- interesting community with lots of free material (e.g. _why's poignant guide, railscasts.com, therubyshow.com, ...)
I'm sure Python is pretty cool as well, but from all I've heard (I had the same question a while ago) Ruby seems to fit me better with its "more fun and freedom" philosophy.
Write some scripts in both. If you already know a few languages, it's pretty easy to pick up the basics.
After that, pick the one you enjoyed more. They're essentially equivalent at this time.
After that, pick the one you enjoyed more. They're essentially equivalent at this time.
It is one of those things were you take about 20 minutes with each language and see which one fits you better.
Python's philosophy is there should only be one obvious way to express something.
Ruby's philosophy is the language should be expressive enough that you can express something in a way that makes sense to you.
The biggest advantage Python has over Ruby is its wealth of scientific libraries, but that may not matter to you much as a web developer.
Python's philosophy is there should only be one obvious way to express something.
Ruby's philosophy is the language should be expressive enough that you can express something in a way that makes sense to you.
The biggest advantage Python has over Ruby is its wealth of scientific libraries, but that may not matter to you much as a web developer.
python for sure. you can use it with app engine, whereas ruby on the app engine jvm is less mature.
take a look at some source code here to help you get started:
http://developeradvocate.appspot.com/id/1005/AppEngineBlog-(...
http://code.google.com/p/appengineblogsoftware/source/browse...
take a look at some source code here to help you get started:
http://developeradvocate.appspot.com/id/1005/AppEngineBlog-(...
http://code.google.com/p/appengineblogsoftware/source/browse...
I come from a c# and php background and don't know ruby, for what it's worth.
python. coming from almost the same background python was easier, ruby was just.. annoying, its all hype and IMO will soon crash.
Also I really like the speed at which you can write up a python script to solve a problem.
Also I really like the speed at which you can write up a python script to solve a problem.
Python
For what it's worth, several universities have chosen Python to teach introductory CS rather than Lisp/Scheme. Also NASA, Industrial Light and Magic, Disney, etc have chosen Python. But as others have pointed out, try out both and see which one feels more "natural" to you. For me, Python was like "executable pseudo code" and I found I could grok the batteries included libraries much better than anything that Ruby had to offer at the time (about v2.1 vintage).
I work professionally in Django. Django is nicer starting out, but it's starting to chafe. I'd rails, even if it is a "grass greener" type situation.
What are your hangups with Django?
I've gone through the same so I'm wondering if we are running in to the same kind of issues.
I've gone through the same so I'm wondering if we are running in to the same kind of issues.
Forms are a fragile waste of time 80% of the time.
Only reusable modelforms + generic views really redeem them in my eyes.
The ORM is enjoyable but terrible for doing mass migrations. I've had to do some pretty ridiculous backflips just to get migrations to finish on our VPS.
The utter lack of real migrations. For. Fuck's. Sake. Makes it impossible to make any rapid changes to your models without thinking, "OH GOD WHAT AM I GOING TO BREAK!?!"
There are random and strange install-specific errors that will crop up and we'll either have to reinstall python/django, the OS, or ignore it and trudge on.
And there won't be any mentions of said problems on the mailing list to speak of either. (These kinds of things have occurred on OS X and Win32 both, so don't start pointing fingers.)
The incredible awkwardness of AJAX in Django. Utterly useless. It apparently suited Jacob and Adrian to pretend javascript didn't exist in their world.
It's opaque, doesn't support multiple databases, doesn't support non-relational databases, and it's nearly impossible to modify/rip out any given portion of the framework. It's the epitome of what people hate about full'ish stack frameworks.
I'm to the point where I no longer feel Django is saving me any time. The crippling of templates doesn't create a substantial separation of duties at work because I work with incompetents. Instead I'm left with crippled templates and whiny coworkers.
I'd rather work with Werkzeug/Web.py/Sinatra/Rails at this point. At least Rails was designed to be modular, allowing me to rip the parts I don't like out.
Only reusable modelforms + generic views really redeem them in my eyes.
The ORM is enjoyable but terrible for doing mass migrations. I've had to do some pretty ridiculous backflips just to get migrations to finish on our VPS.
The utter lack of real migrations. For. Fuck's. Sake. Makes it impossible to make any rapid changes to your models without thinking, "OH GOD WHAT AM I GOING TO BREAK!?!"
There are random and strange install-specific errors that will crop up and we'll either have to reinstall python/django, the OS, or ignore it and trudge on.
And there won't be any mentions of said problems on the mailing list to speak of either. (These kinds of things have occurred on OS X and Win32 both, so don't start pointing fingers.)
The incredible awkwardness of AJAX in Django. Utterly useless. It apparently suited Jacob and Adrian to pretend javascript didn't exist in their world.
It's opaque, doesn't support multiple databases, doesn't support non-relational databases, and it's nearly impossible to modify/rip out any given portion of the framework. It's the epitome of what people hate about full'ish stack frameworks.
I'm to the point where I no longer feel Django is saving me any time. The crippling of templates doesn't create a substantial separation of duties at work because I work with incompetents. Instead I'm left with crippled templates and whiny coworkers.
I'd rather work with Werkzeug/Web.py/Sinatra/Rails at this point. At least Rails was designed to be modular, allowing me to rip the parts I don't like out.
Absolutely agree with you on most of the points. A couple of quibbles - Django now supports multiple databases (as of 1.2) and South (http://south.aeracode.org/) is more or less the default migration tool nowadays and is OK for most jobs.
Personally, I find generic views to be useless for anything but the simplest of prototyping. Making them functions rather than callable classes was a big mistake IMHO. I very rarely use them in a serious project.
Another pet hate is UserProfiles - you have to use a separate model if you want any custom fields for your users which entails a join whenever you want to use it. It's been a ticket for years but nobody seems willing to fix it.
I agree with you 200% on templates and am in a very similar situation. Having to write convoluted code in template tags for the simplest of things is frustrating, when you can have simple function calls and template macros in Mako and Jinja2.
I'm not hugely fussed about AJAX myself - I tend to keep things simple in the views and just pass JSON back and forth and jQuery does most of the front-end work. I disliked the Rails way of binding everything to a particular JS library, not sure if it's still done that way any more.
Django is OK for certain projects. What annoys me though is that like Rails, it has gotten such mindshare in certain companies that they call themselves "Django shops" and want to use it for everything, without considering alternatives. Personally I stay well clear of it for my own projects - Pylons, Werkzeug, SQLAlchemy et al are a lot more fun to work with.
Personally, I find generic views to be useless for anything but the simplest of prototyping. Making them functions rather than callable classes was a big mistake IMHO. I very rarely use them in a serious project.
Another pet hate is UserProfiles - you have to use a separate model if you want any custom fields for your users which entails a join whenever you want to use it. It's been a ticket for years but nobody seems willing to fix it.
I agree with you 200% on templates and am in a very similar situation. Having to write convoluted code in template tags for the simplest of things is frustrating, when you can have simple function calls and template macros in Mako and Jinja2.
I'm not hugely fussed about AJAX myself - I tend to keep things simple in the views and just pass JSON back and forth and jQuery does most of the front-end work. I disliked the Rails way of binding everything to a particular JS library, not sure if it's still done that way any more.
Django is OK for certain projects. What annoys me though is that like Rails, it has gotten such mindshare in certain companies that they call themselves "Django shops" and want to use it for everything, without considering alternatives. Personally I stay well clear of it for my own projects - Pylons, Werkzeug, SQLAlchemy et al are a lot more fun to work with.
>Django now supports multiple databases (as of 1.2) and South
I don't get to use either at work.
I don't really care for SQLAlchemy either.
I don't get to use either at work.
I don't really care for SQLAlchemy either.
Ok. We're on the same track then but I would put it a little more friendly at the moment but I probably haven't got enough experience yet.
I spotted werkzeug ('tool' in German) a while ago and it definitely looked very good.
I've built 3 sites in Django now, two small ones and one larger one. The small ones worked fine, the larger one Django immediately turned from 'enabler' in to 'straightjacket'.
I hand coded the forms so they're not even part of the frustration, the ORM is definitely a limiting factor, agreed with the AJAX oversights, even the simplest stuff and you're immediately out of django in to 'roll your own' mode.
Not having multiple db connections was one of the first things I was wondering about how serious this package really was, after all almost all non-trivial setups will access multiple dbs, even if not at the same time then sequentally.
Import wasn't much of a problem for me because I did the import by talking to the DB exclusively, I had the 'export' in exactly the right format for import into the mysql django tables. But it would have been nice to have a tool handy to do that.
The admin is fine until you have more than just a toy dataset, and the way in which you configure the admin has altogether too many little 'magic' steps in it.
So far it's been a mixed bag. For small sites probably a good fit, for larger ones probably not.
Fully agreed on the template limitations, and the lame excuses around not having some basic functionality in there are really trying my patience.
But I haven't seen anything yet that I felt really was a step up from the rest.
I'll keep looking though.
I spotted werkzeug ('tool' in German) a while ago and it definitely looked very good.
I've built 3 sites in Django now, two small ones and one larger one. The small ones worked fine, the larger one Django immediately turned from 'enabler' in to 'straightjacket'.
I hand coded the forms so they're not even part of the frustration, the ORM is definitely a limiting factor, agreed with the AJAX oversights, even the simplest stuff and you're immediately out of django in to 'roll your own' mode.
Not having multiple db connections was one of the first things I was wondering about how serious this package really was, after all almost all non-trivial setups will access multiple dbs, even if not at the same time then sequentally.
Import wasn't much of a problem for me because I did the import by talking to the DB exclusively, I had the 'export' in exactly the right format for import into the mysql django tables. But it would have been nice to have a tool handy to do that.
The admin is fine until you have more than just a toy dataset, and the way in which you configure the admin has altogether too many little 'magic' steps in it.
So far it's been a mixed bag. For small sites probably a good fit, for larger ones probably not.
Fully agreed on the template limitations, and the lame excuses around not having some basic functionality in there are really trying my patience.
But I haven't seen anything yet that I felt really was a step up from the rest.
I'll keep looking though.
>the larger one Django immediately turned from 'enabler' in to 'straightjacket'.
Yeah, I've had a bit of enlightenment regarding that. I think the trick is to eventually treat it a bit like Philosophy.
Toss aside what you encounter to be a problem, take with you what is useful.
The signals backend and request object encapsulation has proven invaluable, combined with the corpus of snippets and tricks out there.
The templates are really starting to get on my nerves. Probably going to use Jinja2 outside of work here on out.
well, it's been a step-up from what I've experienced because of a perfect storm occurring from the power of combining generic views, quick-n-easy pagination, the ORM, and template inheritance. I've become incredibly productive in Django in spite of the annoyances.
In fact, you may want to check out "annoying django" for some hacks and neat features to deal with some painpoints.
This includes an AJAX view decorator to quickly pass json back and forth.
Yeah, I've had a bit of enlightenment regarding that. I think the trick is to eventually treat it a bit like Philosophy.
Toss aside what you encounter to be a problem, take with you what is useful.
The signals backend and request object encapsulation has proven invaluable, combined with the corpus of snippets and tricks out there.
The templates are really starting to get on my nerves. Probably going to use Jinja2 outside of work here on out.
well, it's been a step-up from what I've experienced because of a perfect storm occurring from the power of combining generic views, quick-n-easy pagination, the ORM, and template inheritance. I've become incredibly productive in Django in spite of the annoyances.
In fact, you may want to check out "annoying django" for some hacks and neat features to deal with some painpoints.
This includes an AJAX view decorator to quickly pass json back and forth.
Django != Python and Rails != Ruby. There are other solutions in either language that might suit your project better.
>There are other solutions in either language that might suit your project better.
What I use at work isn't up to me. I'm paid to work, not whine and whinge about the spade in my hand.
What I use at work isn't up to me. I'm paid to work, not whine and whinge about the spade in my hand.
Who said anything about whining ? It is your duty as a professional to promote what you consider the best tool for the job. A spade isn't much good if your job is to rake some leaves.
Of course your advice might be overruled for perfectly valid technical or non-technical reasons. But by keeping silent and not suggesting alternatives you are doing yourself and your employer a disservice.
Of course your advice might be overruled for perfectly valid technical or non-technical reasons. But by keeping silent and not suggesting alternatives you are doing yourself and your employer a disservice.