Ruby has a distribution problem | Hacker News Reader

Ruby has a distribution problem

madstop.com

23 pointsluckystrike6 comments

  For example, rubygems (probably my least favorite ruby
  software of all time) basically require that you always try
  to load them, because their design stupidly requires that 
  you know whether a given piece of software is installed via 
  rubygems or some other mechanism.

Nearly all libraries nowadays are installed via RubyGems. For most of its life, RubyGems has been the "de facto" way to install libraries, but not the 100% officially-sanctioned route. As such, it's necessary to require RubyGems in first, then the libraries you want to load. This takes all of 10 seconds to learn.

The poster has missed the point somewhat when it comes to the use of vendor. "vendor" is used in situations where you have to remain fixed to a certain version of a certain library AND you're not 100% confident that your deployment environment will have that version of the library installed. In this way, it's a better solution than just praying the remote server has a certain library installed or ending up with a script that fails on the library version assertion, as with Perl. Overusing vendor is, however, a lazy way of doing things, and the sloppy programmers this guy has spoken to do not represent the community as a whole.

From the comments:

  To me, this is one of the really big things that defines 
  Perl as a mature language community: Perl people don't do 
  this nonsense.  There's no "vendor," and you're looked at 
  like you're out of your mind if you distribute copies of 
  other people's modules with yours instead of declaring 
  versioned dependencies in your Makefile.PL.

(Good) Ruby people don't do this nonsense either. RubyGems supports you specifying the gem name and required version (or required minimum version) in a similar, or better, way than Perl.

This is an over-rated post telling us about a problem that only exists in the ignorant. It's cut from the same cloth as all the misinformed "Twitter's Dropping Rails!" posts and I'd expect better from the voters on HN.

Amen.

The bit about Perl isn't completely true either. Some people have Makefile.PLs that require CPAN modules; until very recently they had to ship the CPAN module along with their module. (Now we have the "configure_requires" directive in the META.yml which will allow CPAN or CPANPLUS to download that module before running Makefile.PL.)

  This is an over-rated post telling us about a problem that only exists in the ignorant. 
  It's cut from the same cloth as all the misinformed "Twitter's Dropping Rails!" posts 
  and I'd expect better from the voters on HN.

Cross Platform Software Distribution is a challenge for any language/technology. I guess the upvotes for this submission do not imply readers here agree with the viewpoint on Ruby given in the article, but rather think it is an interesting topic worth discussing. (I might be completely wrong in this assumption)

I am an active user of Ruby, and agree with you that the author is making over generalized sweeping statements such as: "yet it's the standard, recommended practice in the Rails community, because it makes it easy to "guarantee" behaviour in a given environment"

There is no silver bullet for software distribution in any particular language. One has to be smart and pragmatic enough to weigh in the pros and cons of static linking/vendoring in their particular case, and then take a wise decision on it.

Swings and roundabouts.

Personally, I use Ruby for stand-alone apps more than for Rails. I do command line tools and Mac apps using RubyCocoa. I can't guarantee that my product functions as planned if I can't control what code it uses.

For libs which belong to the core OS, I am comfortable with using shared libs. These libs are very well documented, and the interfaces don't move. Any changes made by the OS vendor are generally for fixing bugs.

For everything else, I have no guarantee, and hence little trust, that the developer isn't going to change their lib in a way that breaks my code. In such a case, I much prefer to take control over that lib by bringing it into my own project as a static lib. I give my app it's own auto-updating feature, and I take responsibility for keeping the static libs up to date. That takes care of potential security issues.

Not so much a distribution problem, but a platform problem - I cannot get Ruby to compile on an Itanium HP-UX box - even the HPUX ports site says it won't work :-(

If anyone has got it to work please let me know!

Reply on news.ycombinator.com