Slashdot Mirror

← Back to Stories (view on slashdot.org)

RubyGems' Module Count Soon To Surpass CPAN's

Posted by timothy on from the we-finally-know-who's-counting dept.

mfarver writes "According to the data gathered by modulecounts.com, the total number of modules checked into RubyGems (18,894, and growing at about 27/day) will probably exceed CPAN (18,928, and growing about 8/day) this week."

30 of 206 comments (clear)

  1. Real use by isorox · · Score: 4, Interesting

    Obviously there's some real projects out there using Ruby, is it mainly internal stuff? There's some big contenders for things like PHP (wikipedia probably being the biggest). Does Ruby factor in to any public-facing websites of note? Or is it mainly used in the corporate space in the area where you often find tomcat?

    1. Re:Real use by graznar · · Score: 3, Informative

      Here's a quick list just off the top of my head: * YellowPages.com * All of the 37signals apps (Basecamp, Campfire, etc.) * Hulu * Scribd * LivingSocial * Penny Arcade * GitHub * Twitter (backend powered by a ton of stuff but their frontend is mostly Rails) * Chow.com * Oracle.Mix * Shopify * Justin.tv * Crunchbase There are a ton more public facing and even more (as you mention) sort of "behind the firewall" type stuff. Ruby (especially Rails) has stepped up as a pretty major contender in the web development arena. :)

      --
      [ check out my ruby book @ http://ww
  2. How many of those are maintained by cerberusss · · Score: 4, Interesting

    Big numbers, but you have to be very careful what you pick. Do you want to go with community-based support? Pick the most-used module. Want to maintain it yourself? Pick the one with the best code quality. Do you need specific performance? Test them all. Et cetera.

    Besides, it's pretty obvious that Perl usage is slowly declining. The idiosyncrasies of Perl 5 get very annoying. And Perl 6 has been 10 years in development and is still not very popular in production and everybody is switching to more modern languages like Python and Ruby. At my job (a scientific institute), we're ditching Perl 5 for Python.

    --
    8 of 13 people found this answer helpful. Did you?
    1. Re:How many of those are maintained by Lazy+Jones · · Score: 3, Insightful

      The idiosyncrasies of Perl 5 get very annoying.

      Like what? I can't really think of anything annoying enough to bear mentioning, except perhaps that typos are hard to find with warnings off (and sometimes with warnings on as well).

      everybody is switching to more modern languages like Python and Ruby. At my job (a scientific institute), we're ditching Perl 5 for Python.

      Ruby is certainly modern, but Python? It's a poor choice IMO when it comes to fixing Perl's biggest problem, threading support/concurrency due to its GIL, some Ruby implementations fare better. We'll stick to Perl for now, our parallelizable problems are generally tackled using Gearman and apart from a lack of decent programmers, we haven't found any real issues lately.

      --
      "I love my job, but I hate talking to people like you" (Freddie Mercury)
    2. Re:How many of those are maintained by Chapter80 · · Score: 4, Interesting

      Besides, it's pretty obvious that Perl usage is slowly declining.

      I can't comment on the trend (declining or ascending?), but it sure looks like perl is still pretty popular, on this comment from last month.

      It says:

      Dice has a lot more programming listings than Monster.

      Java - 14824 .Net OR C# - 10496
      C++ - 5789
      Perl - 4664
      PHP - 2499
      Python - 2196
      Objective C - 1267
      Ruby - 1169
      Cobol - 638

      (bolding emphasis mine)

    3. Re:How many of those are maintained by gtirloni · · Score: 2

      I haven't coded a line of Perl in a while. It's mostly fixing bugs in legacy Perl code and migrating everything to Python. Ruby seems to have some traction now but I find it's as hard to read as Perl. They have to much implicit information. It's convention over explicit... I don't like that.

      --
      none
    4. Re:How many of those are maintained by happy_place · · Score: 4, Informative

      I think Perl is a fantastic language--in fact it's my favorite language of all time. Heck, I just released a new tool at my work last week using Perl and CGI to help organize about 4 years worth of file changes from an active CVS archive into relevant categories.

      Perl's not a language for the faint-hearted, however. It is not a language you sit down and instantly you have a webpage going--which is what most people want to do these days when it comes to casual programming. For that, PHP and Ruby seem to be a lot more accessible.

      I've been using Perl for over ten years now, and I find that I'm still learning something new about how to use the language in fascinating ways--pretty much every day. Nothing compares to Perl's community. You can talk with experts daily if you like, on sites like http://www.perlmonks.org/ and the documentation is all accessible at http://perldoc.perl.org/ or with every install of perl by just typing perldoc... I love how easy it is to move data about. It really was the first language to fully incorporate hashing as a basic operator and though variable sigils confuse a lot of people used to simpler programming languages, such notation allows for some amazingly flexible operations without the need to create lengthy method calls for every basic operation on your data structures. In Perl every symbol has specific/distinct meaning and interoperates with all others, and those combinations make for some very powerful programs with few lines of code--like how you can load full hashes by acessing them with the array operator as hash slices... and who can compare to Perl's enhanced regular expressions, especially the latest from v. 5.12...

      Anyhow there are languages for the pedantic, there are languages for your project managers and your CS grads, and for your code-generators--or for outsourcing to India, and then there's languages that really get your inner geek going... and Perl definitely reigns supreme for my inner geek. :)

      In fact, Some people call it magic.

      --
      http://www.beanleafpress.com
  3. How many of those modules? by Anonymous Coward · · Score: 5, Funny

    How many of those modules are solely focused on converting a string to uppercase?

  4. Irrelevant statistic... by pedantic+bore · · Score: 5, Insightful

    It doesn't matter how many modules there are. It matters how many solid, well-documented modules there are that will continue to get updates and support.

    I have no opinion over how much goodness there is in CPAN versus RubyGems; maybe RubyGems is really pulling ahead. But out of nearly nineteen thousand modules, how many really matter? (and how many are just another XML library that's just slightly different and incompatible with the bajillion other XML libraries already out there?)

    --
    Am I part of the core demographic for Swedish Fish?
    1. Re:Irrelevant statistic... by Aladrin · · Score: 4, Interesting

      Even as an amateur, this is something I worry about. I realized pretty quickly how dangerous monkey patching is, but others seem to think it's the answer to everything. Need a special string manipulation function? Name it something generic and slap it on String. UGH.

      I even saw where Rails had added a function to String that rewrote the request string. Then others started using it, because it was so useful. And then Rails changed the function. All those people using it for unintended functionality were now broken because the change they made wasn't something you'd expect a function named that to do.

      That function was 'camelize' and is aliased to 'camelcase'. Here's the issue: It also converts '/' to '::'. This is completely unexpected from the name.

      Now, I get that upgraded to a different version of a library will have some unexpected effects, but you shouldn't have to worry about something so basic as this.

      --
      "If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
    2. Re:Irrelevant statistic... by e70838 · · Score: 5, Interesting

      I fully agree. I am a Perl programmer. I like very much the syntax of ruby. At first, it seems to be as expressive as Perl without the need of cabalistics symbols ($ @ %). But when I discovered the libraries with all the inconsistent names and all the silly aliases, I felt I can wait until they fix all that.
      It is normal that people writes their own modules: the default libraries are too crappy.

    3. Re:Irrelevant statistic... by freedumb2000 · · Score: 4, Insightful

      I am a huge ruby fan, but I must agree. Much more relevant would be a graph with module count and factoring in development activity. In reality, a huge number of the gems are orphans, or come never out of alpha.

    4. Re:Irrelevant statistic... by EsbenMoseHansen · · Score: 2

      While I agree that changing the functionality of a library function underneath users in a non-backward-compatible way is bad, this has nothing to do with monkey-patching. What you describe would be the same in any language supporting library function, even if it was named "char* camelize(const char* input);" and written in C.

      --
      Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
  5. Prototyping and Small Projects by eldavojohn · · Score: 5, Interesting

    Obviously there's some real projects out there using Ruby, is it mainly internal stuff? There's some big contenders for things like PHP (wikipedia probably being the biggest). Does Ruby factor in to any public-facing websites of note? Or is it mainly used in the corporate space in the area where you often find tomcat?

    What we use it for at my company is quick prototyping. Especially with Rails. But it's important to note that Ruby is the language and Rails is the framework. These modules could just be a niche field like academia finding it easy to write and share these modules through this site. I'd say that's unlikely given the number and you're most certainly seeing businesses promote some of this. I will say that we actively use hundreds of gems and I'm not sure what the average module:gem ratio would be in these projects -- as far as I can tell, I think it's 1:1 on a lot of the major ones we depend on.

    Here's a list of some websites you might know using Ruby. The most notable is Twitter who I think is starting to componentize its pieces and move the high load intensive pieces to Scala. That's not to say they're completely off of Ruby but I think it's a sign that Rails needs a little more maturity before it is going to be seen on a website the size of Facebook. You'll see small to medium efforts excel at Ruby on Rails but the very very giant beasts are still too big for it at the moment. That means that you have a high number of websites using it but the representation is skewed against it since your big sites that everyone use aren't going to trust its maturity yet.

    great language. It's simple, elegant, clean and it is versatile. Rails muddies that up a bit but Rails is great for prototyping web applications. In my opinion, the increase in the number of modules shows how versatile the language is and how wildly people want to extend it. It really does have a lot of metaprogramming facets that I've been impressed with and I think that we're going to see a rise of languages like Ruby and Clojure that allow you to do interesting things like write a domain specific language (DST). But will they ever usurp the big old giant languages that command a presence? I guess only time will tell. For web programming, I prefer Ruby to Java when prototyping or writing anything for less than thousands of users. That's where it stands right now but Ruby usage has grown by leaps and bounds and I don't think this module tracking story is a fluke. I think we'll see a steady rise in Ruby modules as people explore its potential. The quality, the performance, the diversity, the revenue can all be questioned but the number of modules is most likely there.

    --
    My work here is dung.
    1. Re:Prototyping and Small Projects by Anonymous Coward · · Score: 3, Insightful

      Huge sites like Twitter or Facebook have special needs that are unlikely to be there for 9 out of 10 other sites. Sure, it's an honor to have "your" language picked at some point for such a large scale / high availability service, but they will eventually switch to something else as the technology evolves, or the needs of the site change, and so on.

      Bottom line: if Twitter or Facebook used Ruby at some point in time for certain things doesn't mean it will be good for you and your site. It means it has certain qualities and you should research whether they're useful to you.

  6. Never mind the quality, feel the width by petes_PoV · · Score: 5, Insightful

    Personally I don't care how many modules any repository has, just so long as the ones I want to use work properly. That will always be my primary measure of success, followed closely by how well they are documented and then by how easy they are to find and use.

    --
    politicians are like babies' nappies: they should both be changed regularly and for the same reasons
  7. DLL hell by Jay+Maynard · · Score: 5, Insightful

    I sure hope RubyGems isn't the utter DLL hell that CPAN is. The only time I tried shipping a product based on CPAN stuff, I wound up shipping the entire bundle as one, because there's just no way to download it from CPAN and depend on having the exact versions of the modules you developed with available - and when they're not, you're stuck in a messy cycle of upgrade dependencies and API incompatibilities that are almost impossible to resolve.

    --
    Disinfect the GNU General Public Virus!
  8. Re:Quick! by siddesu · · Score: 2

    I would, but I use perl instead of ruby.

  9. pl-2-rb.pl converted 17,894 of those by Anonymous Coward · · Score: 3, Funny

    pl-2-rb.pl converted 17,894 of those.

  10. Quality has never been a concern of Rubyists. by Anonymous Coward · · Score: 3, Interesting

    In general, quality and correctness have never been major concerns of the Ruby, and especially Rails, communities. Their goal is to produce large amounts of software quickly, even if it's shitty, doesn't do what it's supposed to, and even if it outright fucks up. It doesn't surprise me at all that they'd produce a blatantly incorrect graph like that.

    The Ruby and Rails communities consider things like monkey patching and duck typing to be acceptable in large-scale applications. Anyone with any experience developing significant software systems knows that those are among the stupidest things you can do, and they do adversely affect the quality of the software system.

    The mere concept of monkey patching should throw up red flags immediately. It's a horrible idea to change code at runtime, especially when that code is part of widely-used standard classes like String or even Object. Not only does it reduce the quality of your own code, but it can easily affect completely independent libraries your app may be using.

    Then there are the ActiveRecord shenanigans. It makes Ruby developers think they don't need even a basic understanding of relational databases, so they have no idea what it's actually doing under the hood. Then they wonder why their app's performance is absolutely horrible. Well, that'll happen when your ORM fucks up and pulls in 1.5 million records into memory just to do some filtering that could have easily been done in the database.

    I'd rather have CPAN's thousands of modules, most of which are extremely high quality and reliable, versus a larger number of shitty Ruby "gems".

    1. Re:Quality has never been a concern of Rubyists. by Bigos · · Score: 5, Insightful

      The fact that Ruby and Rails make bad programming practices possible doesn't prove anything. The same can be said about any language. I'd rather apply something that has been already said about Lisp. Ruby and Rails are programmer amplifiers, making performance of bad programmers worse, and good programmers even better. Monkey patching can be a very powerful approach, if used properly. It makes possible to write very readable code. It's not so much about changing your code but rather extending it. It can be a very useful technique if used properly.

    2. Re:Quality has never been a concern of Rubyists. by SanityInAnarchy · · Score: 2

      That's tricky.

      There is a large and vocal Ruby community of behavior-driven design. Tools like RSpec in particular show just how well this works in Ruby, compared to other languages, and all the major projects (including Rails) use and encourage tests -- basically, if you want a change in Rails, you're going to need to write a test which describes the change, which fails on the current trunk and passes with your patch.

      But there's also a large and nearly silent community of people who just throw up a gem (because of how absurdly easy it is) without much in the way of docs or tests. And that's cool, too -- even if your project sucks and is in ridiculously early alpha, even if you're still learning the language (or learning to program), it means it's easy to get at your code.

      I haven't used CPAN enough to know how it compares, but there are very good gems, and very bad gems, and very unorthodox gems. I think you have to allow the bad ones to also allow the unorthodox ones, and I think it's a strong community overall, but CPAN was pretty damned good, so we might have a ways to go.

      What I think we need more of is a way to rank and rate gems, so you don't have to be on the mailing list for months just so you know offhand that Nokogiri has replaced Hpricot (and certainly rexml) as the best html/xml parsing suite.

      --
      Don't thank God, thank a doctor!
  11. According to modulecounts... but then again... by mr_mischief · · Score: 4, Informative

    search.cpan.org states that there are 88,679 modules in 21,580 module distributions. It further says there have been 63,291 uploads by 8659 uploaders (authors).
    Perl also has over 600 modules in the core distribution (as of 5.12.2 anyway).

    On CPAN, a "module" is a module, and that's what it sounds like. A module is a program library that can be used by an application programmer. A module distribution is several related modules in a package. Some packages contain dozens of modules. Some may also contain example applications or helper applications along with the modules. PyPi also has packages which can be collections of modules. I don't mess with Python enough to tell you if that's common.

    So, RubyGems has over 18,00 "gems", but what does that mean?

    On RubyGems, it seems a "gem" can be anything. There are libraries there, sure. There are also applications. One, for example, is "vmail", which is a hack to let you read your GMail account in vim (using lynx for HTML mail viewing). Another is "rake", which is a software build program. You do have big frameworks pushed out as gems like "rack". There are smaller library modules that look useful, too. Then there's some stuff with no docs, no home page, and no apparent use. I found one "gem" that claims to redefined '==' to be more useful than in the standard library, but was all of 4 lines with no documentation.

    RubyGems seems to have no real organization other than new, recently updated, popular, and alphabetical. There is a search.

    CPAN and PyPi both have hierarchies of topics through which one can drill down. They have search, too. PyPi has probably the best combination of search and drill-down features of the three.

    CPAN has some things it's pretty clear RubyGems doesn't. It has an automated build and test system for modules. It has a ticketing system for the modules right there in the public repository. It has a rating system for the packages. It has 228 mirrors worldwide for downloading the packages, too.

  12. Re:But CPAN is shit by Jimmy+King · · Score: 2

    It's fairly straightforward where modules get installed. I personally find it great. When the distribution handles their pre-packaged modules sanely, it makes it very easy to tell which modules were installed by the distro and which from cpan. With python, at least on Debian, distro modules and pypi modules all get dumped in the same place. That gets a bit messy to me.

    I also prefer CPAN with a more centralized repository for the code. Pypi seems to install crap from all over the place, it could pull from someone's personal website, sourceforge, wherever. It seems to me that CPAN is more likely to be more resilient and consistent than Pypi as Pypi ages and old modules stop being hosted and the centralized aspect gives at least a better possibility of having some sort of central checking for authenticity and a number of other possibilities that may or may not actually be happening - but they at least could.

    If you've ever been involved in large scale Perl development, you'd also quickly discover that your distro of choice may not actually provide every useful Perl module. I've got a document I maintain for setting up new installations of our platform that includes a list of which modules to install from the apt repository and which modules need to be installed from CPAN either due to not existing in apt at all or needing functionality not included in the much older version of the module that is frequently included with Debian. It's not a huge list, but it's probably 10 modules that I install from CPAN, some of which install a few others as dependencies, although to be fair to hose dependencies may be included in apt as I just tell CPAN to auto install them currently.

  13. Good choice by bill_mcgonigle · · Score: 2

    The only time I tried shipping a product based on CPAN stuff, I wound up shipping the entire bundle as one, because there's just no way to download it from CPAN and depend on having the exact versions of the modules you developed with available

    Good choice, that's what you're supposed to do if you're shipping a product. Perl includes tools to help you do this. Fortunately, your app was probably stored on $1 worth of storage.

    You could also specify a no-breakage OS (e.g. RHEL, debian stable) and write your app to what they're shipping.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  14. Re:But CPAN is shit by sqldr · · Score: 2

    This is ok on a single machine, but if your entire system of 90+ servers is fully configuration-managed, you can't automate this. Perl, PEAR, pythonforge, ruby gems and any other suchlike are BANNED :-) I've written a python script to convert pear tarballs into rpms :-) I trust rpm and that is the only package installer on my systems.

    --
    I wrote my first program at the age of six, and I still can't work out how this website works.
  15. Great, now let's work together. by bill_mcgonigle · · Score: 4, Interesting

    Folks with a few spare cycles/resources who are growing tired of these 'module' measuring contests might want to throw a bone to Parrot VM. Write a module in ruby, use it from perl6, python, lua, tcl, whatever, or pick any combination above.

    I won't wave the red flag explicitly, but suffice it to say I look forward to good ruby performance on parrot.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    1. Re:Great, now let's work together. by Eivind+Eklund · · Score: 2

      I have less hope for that than you. Using libraries (modules/frameworks/whatever) written for another language isn't usually as nice as using something that's native. There's different conventions, and there's usually features in each language that makes for an improved experience - for that language.

      For instance, in Ruby, I'd expect an API to actively use blocks (continuations) for resource tracking, and a DSL based on symbols and blocks would be common. Doing this in Python or Perl would be weird.

      In Python, I'd expect docstrings, and I'd expect exceptions, and the use of the standard module system, with one module per file, and the need to use import to get at the right constants etc.

      In Perl, I'd expect perldoc. I'd not expect exceptions, as that's not really well supported (at least in perl 5). And I'd expect there to be distinctions between references and 'real values'.

      Overall, I think that anything that's written in one language and automatically accessed from another language will interface clumsily. And if you have to write an abstraction layer to make it work, you often might as well have a native module without the quirks.

      Eivind.

      --
      Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
  16. Re:But Python is shit due to: by TapeCutter · · Score: 2

    Python doesn't use curly braces for compound statements, that's what the indents are for and why it's important to get them right. Personally the indent thing is the only part of Python that really irritates me since some editors can fuck up the tabs beyond repair. I would love to see Python use C style compound statements but even without that it's still the best programming glue I have used.

    --
    And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
  17. Re:After 10 years? by Bill,+Shooter+of+Bul · · Score: 3, Interesting

    Ok, so we can cancel all Math classes after 10 years right? Because anything logical should take less time to completely learn and understand. Lets face it: Math professors are lazy bastards that don't deserve their research grants. /sarcasm

    --
    Well.. maybe. Or Maybe not. But Definitely not sort of.