From Python to Ruby: Taking a Step Backward

> Ruby feels like a “more than one way” type of language more closely related to Perl.

Gem issues aside, which Perl doesn't tend to have because CPAN is so rock solid, that was exactly the reason I didn't continue with Ruby when I checked it out, somewhat in depth, a few years ago: Ruby is Perl with OO done right, which is nice, but if you use Perl professionally, Ruby will not provide you with an alternative way of thinking the way Python does.

> My assumption is that devs in Python try to stick to the Pythonic way of doing things across modules, which helps maintain interoperability.

Yep. And that's also what I tried to do when I first started with Ruby, until another commenter explained to me that Ruby is different.

We were discussing the syntax of RSpec, and I was griping that RSpec was so linguistically different. Commenter explained that RSpec is very clear that it wants to have a different flow than pure Ruby because RSpec looks like a set of user stories. That means I'm going to have a hell of a time trying to stick RSpec into another use case, but I can't argue that the rationale for RSpec's DSL makes sense.

> Ruby feels like a “more than one way” type of language more closely related to Perl

Which is somewhat ironic, given that Perl has one distinct CPAN, and the CPAN tools are so utterly solid.

I had the same experience as you and OP, doing an RoR implementation from the operations end was a tangled mess of gems with various mangled dependencies onto one another, with those dependencies being to certain badly documented or undocumented version numbers.

Also, when I did this implementation several years ago, the core RoR and gems documentation web pages were a mish-mash of broken links.

These problems drew me to reading the blog postings of the mongrel gem creator, to try to figure out how to get mongrel interacting with the other gems properly. The blog did not exactly inspire my confidence in the software.

In fact, the project went over budget and over deadline. It is the project which went most off the rails, so to speak, in my 2+ years at that company - even more than the attempt to implement Sharepoint. The outside developers thought they would "save time" by doing it all in RoR, but they failed to deliver a production ready system. I know that Twitter made a great effort to pull itself off its initial RoR base, and that it is widely said that RoR is not scalable. It is possible it will straighten out over time, I remember back when Java application servers were slow resource hogs with poor frameworks. My initial experience with RoR has left a sour taste in my mouth. Maybe the operations background of this person has significance - it may look OK from the developer standpoint, but the production operations end needs a lot of work.

I think the "understands the language and ecosystem better" is critical, but my expectation is that I need to learn a subset of key gems better more than anything else.

Every hardcore Ruby-ist that I've known has owned a Mac as their primary dev machine. I'm sure that there are plenty of Linux devs out there, but my experience has been that it's heavily Mac-driven. However, by sticking with Linux as my development platform, I'm probably going to learn the guts of gems because I have to get under the hood to make them work on Linux.

Maybe I'll continue to have gem conflicts, but that's okay - I'll know how to hack around them.

No, I agree with the OP. If you want to install some interesting Ruby app or library you quickly find yourself installing all sorts of interdependent gems to get it to work. This is, of course, a matter of YMMV, but I can see where he's coming from.

And with Python, BTW, it's a lot easier, probably because of all the batteries that are included.

This is simply an effect of you having full knowledge of Ruby development management, but not python's. In fact, they are quite similar to eachother.

A pythonist would just say:

"I just install a python environment from virtualenv, git clone an app and type 'pip install -r requirements.txt' and then its all working."

virtualenv ~= rbenv, and pip ~= bundler.

Either set of the two make it easy to install appropriate packages for separate projects.

Now maybe the googleability of this knowledge isn't as great as it could be, but ask any good pythonista and they'll set you on the right track.

90 percent of the time the answer is pip.

Things can get trickier on Windows if there are compiled dependencies. You'd better hope there's a precompiled binary for you in that case.

Please don't make this another 'ruby is better' thing, OK?

Just use 'pip install' and forget the rest, this is overwhelmingly the most common advice. If you don't follow this advice and you still complain about installing Python packages, you are inflicting that damage on yourself voluntarily.

Most things you need to use on Windows have exe/msi installers, if you cannot get pip working on Windows (it's not rocket science though)

You have misread the essay. The author wrote:

Ruby makes heavy use of gems, which appear to be like more complex Python libraries. I say "more complex" because they appear to bolt onto each other far more heavily than Python libraries. If I want to make a complex application run, chances are I'll need five gems to do it... and versioning is extremely important.

The point is that the interconnections between Ruby gems appears to be much stronger than between Python libraries, and I interpret the above to mean that version mismatches occur noticeably more frequently in Ruby than in Python.

It is an attempt to get help, but not in the sense that you're thinking.

Writing helps me solidify what I'm learning as I go, because I have to formalize and explain what I'm experiencing. When I wrote my first gist-post, I was simply trying to capture my own thoughts so I could move on to the next learning experience.

However, I discovered a side benefit: Ruby-ists cannot resist commenting on Ruby posts. The comments, even if critical of me or my approach, have been HUGE in helping me understand what I'm experiencing at a different level. That alone is enough for me to want to post more.

True, but they aren't readily apparent to someone who isn't digging through the weeds of both languages.

I looked at 'Hello world!' and FizzBuzz written in both Python and Ruby, and thought that the implementations looked fairly comparable. I haven't seen enough to convince me that Ruby is vastly different - not to say that it won't happen, but I haven't experienced it yet. I think that's why the gut reaction is to think of Ruby and Python as parallel languages.

The comparison seems natural to me. They're both targeting the "trade performance for developer productivity" niche. Regardless of how different they might be in execution, their intended purposes have much more in common with each other than with C, Java, Fortran, or Haskell, to name a few.

I actually remarked on this on a thread this week: http://news.ycombinator.com/item?id=4888768

I said it was funny that Matz was the only modern language creator not listed in the BDFL Wikipedia entry...but someone went in and changed that shortly after...

Matz is involved with design decisions but is maybe less demanding, given the number of implementations that compete with MRI?

I had not really thought about why Python development generally expected a virtualenv until now. If you haven't been in the Python world at all, virtualenv essentially sets up a miniature development environment within your working folder. System Python might be version 2.7.3, but inside my virtual environment I can run Python 3.0. It's a nice little hack around the problem of multiple Python versions... doesn't solve the root cause, but at least you can stitch it up with one step.

Ruby package management comes down to bundle install.

The packages with C bindings I always run into are Oracle and MySQL libraries. On OS X this is easy. On Ubuntu it is a bit of a pain.

That's really about the extent of the pain.