Hacker News Reader

Comment by migrantgeek | Hacker News Reader

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.

View on HN

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

Reply on news.ycombinator.com