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 ?
23 comments
[ 2.9 ms ] story [ 34.3 ms ] threadI've gone through the same so I'm wondering if we are running in to the same kind of issues.
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.
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.
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.
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.
I don't get to use either at work.
I don't really care for SQLAlchemy either.
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.
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.
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.
After that, pick the one you enjoyed more. They're essentially equivalent at this time.
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.
You can move to Rails once you got the basics of Ruby down -- Rails will make a lot more sense then.
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...
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.
Also I really like the speed at which you can write up a python script to solve a problem.
- 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.