From Python to Ruby: Taking a Step Backward

https://gist.github.com/4242213

by josephmosby • 14 years ago

37 42 14 years ago

gist.github.com

pekk3• 14 years ago

You claim to have worked with Python for some time, yet you don't seem to recognize the parallel between installing several gems and installing several packages. Sometimes you come across a package which doesn't work with some specific OS, that's not the language but the package.

dalke2• 14 years ago

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.

pekk3• 14 years ago

Third-party Python packages depend on each other all the time, and (once again) breakage is a problem with the packages as they are produced, not with the language itself... on Python as on Ruby

edavis• 14 years ago

> Ruby has no Benevolent Dictator for Life like Guido van Rossum ...

Matz? Or is his role just more informal compared to Guido?

danso• 14 years ago

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?

RaSoJo• 14 years ago

Interesting. Given a community, how does the naming of a BDFL come about?

If the original author, say Mr. Hansson, is not interested in taking this task upon himself, can the community elect another individual...especially if some aspect of order needs to be brought about?

TommyDANGerous• 14 years ago

I love both Django and Rails. I like the language of Python more than Ruby, but I like the Rails framework more than Django.

tmcw• 14 years ago

> I thought that there would be a fair amount of similarities between Rails and Django given the structural similarities between Ruby and Python. I could not have been more wrong.

Duh? This is just a silly rant that isn't about anything in particular.

migrantgeek• 14 years ago

I have the same complaint regarding gems. They’ve always seemed more brittle than Python modules.

I have an operations background so I’m used to supporting these apps rather than writing them but I’ve had a lot more trouble in the package management department with Ruby than Python.

My assumption is that devs in Python try to stick to the Pythonic way of doing things across modules, which helps maintain interoperability. Ruby feels like a “more than one way” type of language more closely related to Perl.

peteretep• 14 years ago

> 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.

mtts2• 14 years ago

> 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.

josephmosby6• 14 years ago

> 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.

Ologn• 14 years ago

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.

jasim2• 14 years ago

> If I want to make a complex application run, chances are I'll need five gems to do it... and versioning is extremely important. I was following an application template that clearly spelled out all the gems and versions I would need to build it, but hit my first snarl when one gem wasn't quite prepared for Ubuntu 12.04...

Five gems? I haven't seen very many production Rails applications that can do with just five gems. More gems is mostly a good thing - each does just one thing, and does it well. It is like having more smaller methods instead of a few large methods.

> Are these gem heartburns a common problem in Ruby/Rails or is this mostly due to my ineptitude with the language?

Yes, gem heartburns can happen, but they are not very frequent. I'm sure the author will find that Bundler makes versioning an almost solved problem as he understands the language and ecosystem better. Good luck!

mtts2• 14 years ago

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.

jasim2• 14 years ago

Yes and no. A non trivial project will need multiple interdependent gems. But installing them simply is a matter of running 'bundle'.

josephmosby6• 14 years ago

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.

skrebbel• 14 years ago

why so? Mac is a lot like Linux. I've been having little problems with the vast majority of mature gems even on Windows (especially with ruby devkit around, which automagically temporarily puts a GNU environment in my path to build gems that contain c/c++ code, none of which you'll need to worry about on Linux)

jhawthorn• 14 years ago

You will not run into this problem. Linux is almost always used for production servers and is popular for development as well.

anveo• 14 years ago

While many Rubyists may use a Mac I'm confident the large majority deploy those applications on Linux. Cross OS compatibility issues are virtually non-existent, especially on non-development focused gems.

jneen• 14 years ago

I've been developing on Linux since I started. If someone makes a gem that you can't install because you're using Linux, you probably don't need that gem :).

kingnothing• 14 years ago

You shouldn't hit any issues with gems and linux -- most production Ruby systems use linux.

lampe• 14 years ago

no error message ....

how to help you ???

doctor doctor my body is hurting! doctor:"where?" i just told you MY BODY doctor:"-_-"

hcarvalhoalves• 14 years ago

I would like to know why people compare Python and Ruby by default. There are far more differences than similarities.

josephmosby6• 14 years ago

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.

neutronicus• 14 years ago

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.

grk• 14 years ago

Most rails apps are deployed on linux. I doubt there are any popular gems that depend on OS X. The problem might be with gems' dependencies, but that's a problem with linux, not ruby.

oellegaard• 14 years ago

Seems more like an attempt to get help, rather than a serious post - although I agree that ruby gems are not as easy to handle as python packages.

josephmosby6• 14 years ago

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.

jrajav• 14 years ago

I don't think it's specific to Ruby-ists. Hackers in general cannot resist commenting when you criticize something that they've devoted time and energy to, and found to be cool. I think this is a good thing.

mml• 14 years ago

having worked with ruby & rails both for about 7 years, i've run into my fair share of gem hairballs.

in general, i've had _more_ problems on osx than on linux, mostly due to various ARCH flags required by c extensions.

that being said, the "system rubies" on every linux distro i've used are generally infinitely horrible, and this is likely the case for the poster. system packaged gems are also insanely gross as well.

one of ruby's saving graces is that at least it's not used by the base system for initialization, which has bit me more than once installing a python that conflicted with the system python (though that was many years ago, things may have improved).

rvm has its own issues (and seems to be getting more complex with every rev), but in general, makes for clean living. bundler is nice too.

josephmosby6• 14 years ago

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.

senthilnayagam• 14 years ago

"How can I show you Zen unless you first empty your cup."

If you want to feel better about your python roots and ruby is still not there yet here is the link

http://hammerprinciple.com/therighttool/items/python/ruby

I like ruby and ruby on rails. is it perfect? no, it is evolving constantly .

Anybody can build and release a gem, if people love it it gets adopted more and more, rubygems, rack, bundler, rvm, all came from the community.

So the gem which caused all trouble for you, somebody wrote for solving his itch, released it thinking somebody may use it as well, will it be used by everybody maybe he did not care about, so wrote just enough code to get his thing done, if another ruby programmer finds it interesting uses it, if he finds bugs posts tickets or better fork on github submit a pull request.

Thats the ruby community I know of.

tibbon2• 14 years ago

On the flip side, just googling around for how to get python modules (eggs?) installed was a maddening experience. About 6 different ways to do it, and the documentation was a bit unclear on all of them.

I just install Ruby from rvm (or rbenv), git clone an app and type 'bundle install' and then its all working.

andybak• 14 years ago

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.

pekk3• 14 years ago

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)

ivosaurus• 14 years ago

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.

tibbon2• 14 years ago

Thanks! The issue right now really is the Googlability.

I just searched for "Installing python modules" and of the top 5-6 hits (listed below) none of them mentioned the advice you just gave. The Python 2.7 docs don't mention it at all under their installing modules page. Everything's about RPM and Distutils.

http://docs.python.org/2/install/index.html

http://docs.python.org/release/2.2p1/inst/inst.html

http://stackoverflow.com/questions/739993/get-a-list-of-inst...

https://my.bluehost.com/cgi/help/530

http://stackoverflow.com/questions/9714635/how-to-install-py...

http://discuss.joyent.com/viewtopic.php?id=25044

On the flip side, 'installing ruby gems' does tell you about the gem application, but doesn't mention bundler in the top 5 results.

jtchang• 14 years ago

Python package management comes down to pip install.

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

That's really about the extent of the pain.

up_and_up• 14 years ago

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.

From Python to Ruby: Taking a Step Backward

Related Stories