Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Ruby Programming

Is Ruby Dying? 400

Posted by Soulskill
from the netcraft-confirms-it dept.
New submitter John Moses writes "I have been working with node.js a lot lately, and have been discussing with co-workers if node.js is taking steam away from Ruby at all. I think the popularity of the language is an important talking point when selecting a language and framework for a new project. A graph on the release date of gems over time could help determine an answer. The front page of RubyGems only shows data on the most popular, but I am really interested in seeing recent activity. My theory is that if developers' contributions to different gems is slowing down, then so is the popularity of the language."
This discussion has been archived. No new comments can be posted.

Is Ruby Dying?

Comments Filter:
  • Short answer: no (Score:5, Insightful)

    by gentryx (759438) * on Tuesday December 24, 2013 @03:11PM (#45777689) Homepage Journal
    Long answer: a better indicator is how many Google queries for the respective languages are issued. And those suggest that Ruby is standing stronger than ever [google.com]. Ruby is more than just Rails. And just because there is yet another web apps framework, it doesn't mean that the other ones automatically lose traction.
    • Re: (Score:3, Funny)

      by hjf (703092)

      Silly programmer, you're not an "coder"! You don't know what's cool and what's not. Look at that UID. You must be like, 35! Yuck, old people!

      • by hjf (703092)

        Oops... meant "a coder". I was going to put "an app developer" but changed my mind at the last minute...and forgot to fix the "an".

        • by gentryx (759438) *
          A case of too much plum pudding?
        • by JWSmythe (446288)

          Don't worry about it, QA will catch it before it goes to production. That's the new world of development. Write your code as horribly as you want, someone will fix it later.

      • by Tumbleweed (3706) on Tuesday December 24, 2013 @03:41PM (#45777909)

        Look at that UID. You must be like, 35! Yuck, old people!

        Careful there, kid. :)

    • by Tchaik (21417)

      Nice graph. You'll have better luck with 'javascript' than 'java script' though.

    • by lgw (121541) on Tuesday December 24, 2013 @03:23PM (#45777781) Journal

      How about picking the best tool for the job, rather than holding a popularity contest? Too old-fashioned?

      It's good to avoid going too far off into the weeds, lest you find it impossible to hire someone to support code in some pet language, but that's not the concern here. Of the universe of languages, both mainstream and niche languages commonly used in your niche, pick the one that makes it easiest to develop and support the features in front of you.

      It's pretty obvious someone is playing "what language will look best on my resume" here, and if playing that game is obvious to me from this distance, it will be glaring to hiring managers. Few people are looking for a history of "trendy" (you'd be amazed how fast "trendy" becomes "sad" in tech), while a history of doing the dirty, unpopular, work that keeps development teams productive is always welcome, long after the tech stack fades into obsolescence.

      • by kelemvor4 (1980226) on Tuesday December 24, 2013 @03:54PM (#45778009)

        How about picking the best tool for the job, rather than holding a popularity contest? Too old-fashioned?

        It's good to avoid going too far off into the weeds, lest you find it impossible to hire someone to support code in some pet language, but that's not the concern here. Of the universe of languages, both mainstream and niche languages commonly used in your niche, pick the one that makes it easiest to develop and support the features in front of you.

        It's pretty obvious someone is playing "what language will look best on my resume" here, and if playing that game is obvious to me from this distance, it will be glaring to hiring managers. Few people are looking for a history of "trendy" (you'd be amazed how fast "trendy" becomes "sad" in tech), while a history of doing the dirty, unpopular, work that keeps development teams productive is always welcome, long after the tech stack fades into obsolescence.

        All these pseudo-languages look bad to me when I review resume's. If you want to impress, learn C, C++, Assembler, or a few other real languages. Ruby, C$, VB, Python etc... those can be picked up on the fly if needed.

        • by SuricouRaven (1897204) on Tuesday December 24, 2013 @03:59PM (#45778043)

          Learn C. Almost everything else draws from it. Learn C, and you're half-way to learning anything else.

          • by dunkelfalke (91624) on Tuesday December 24, 2013 @04:58PM (#45778487)

            The problem with it is that if you learn C as first language, you probably will always write C in any language. With all the ugly hacks and trying to reinvent the wheel time and time again.

            I write in C for a living, but frankly, while I love my job, I don't like the language. It is just a bit more high level than a macro assembler and full of crazy behaviour.

            • Quite true. Should see some of my early perl code - it worked, but there were a lot of basic perl common-sense methods I didn't know.

              I only program things as a hobby though, I'm not a professional. Most complicated thing I've written in perl is an IRC bot for a roleplay channel that handles character descriptions, logging and dice rolling.

          • by lgw (121541)

            C worries me these days, unless balanced with something modern, because the coding style that comes with good, maintainable C is entirely the wrong style in any modern language. C proves you understand pointers, and that's great don't get me wrong, but these days you had better be comfortable with exceptions too, because I'm beyond tired of seeing Pokemon code (gotta catch em all!).

        • Depends on the job.

          If you're going in for a web development shop, C, C++, LISP, and ASM are just potential signs that we're wasting the applicants time, or they're wasting ours.

          I mean, granted if you're looking for someone who can help handle billions upon billions of transactions per second, having someone who knows their way around with a real language is handy.

      • by Jack9 (11421)

        > How about picking the best tool for the job, rather than holding a popularity contest? Too old-fashioned?

        How do you judge best tool for the job? That isn't an objective question. How would I know if Ruby is the right tool for me?

        The more useful question is "what does the tool offer" and Ruby doesn't have much going for it. If you are using a tool that uses Ruby (like Gherkin), you have a compelling reason to use Ruby. The cost tradeoffs, for integrating one of the many equivalent languages, usually res

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      Interesting that even though PHP's interest has declined over time (according to the same chart [google.com]), it's still more popular than Python & Ruby combined.

      • I'm sure that has absolutely nothing to do with Wordpress. :)
        • by mellon (7048)

          It probably doesn't. It probably has to do with Drupal.

          • by Algae_94 (2017070)
            Wordpress runs far more websites than Drupal. Drupal sites probably have more useful content though.
            • by mellon (7048)

              Very true, but I suspect the reason behind this phenomenon is that people who use Wordpress are looking for something they don't _have_ to program.

    • Re:Short answer: no (Score:5, Informative)

      by Lisias (447563) on Tuesday December 24, 2013 @03:24PM (#45777795) Homepage Journal

      Nice try (intentionally spelling "java script" is not cute, dude!).

      Here, I fixed it to you [google.com].

      Not a surprise, anyway.

      • by Evil Pete (73279)

        Wow. Still, I would not have guessed javascript would be in (apparent) decline. Sorry already blew my mod points here.

    • by mothlos (832302)

      As a big fan of Ruby generally, I hate to take this side, but Ruby is definitely no longer for the 'cool' kids and the community has been shrinking a bit for a while now.

      Your Google query chart is a bit wonky as it captures all sorts of oddities. Here [google.com] is a revised chart which only looks at Computer + Electronics related searches using Google's categories for everything except Python, which I can't seem to figure out how to get it to appear.

    • I don't think necessarily that's the right metric for figuring out whether or not a language is dead.

      It's very much a fuzzy, qualitative problem.

      My best metric is, "Can you still get a job using this language? and is the work interesting?"

    • by Anonymous Coward on Tuesday December 24, 2013 @03:53PM (#45777991)

      Those of us in industry are very fed up with Ruby and Ruby on Rails, but I think it's much more because of their communities than it is because of the technologies themselves.

      I don't know if there's a polite way of saying this, but far too many of the people involved with those communities are utter disasters who in turn create utterly disastrous software systems. For every Ruby success story we may hear about, there are probably 10 or 20 total disasters that aren't as widely known. The disasters are usually because of the people involved, not the technologies.

      Those of us who've been in the industry for many years, if not decades, and have had to engage in hiring over the past 8 or so years will know what I'm talking about. We have to deal with candidates who have no formal education at all in computer science, software engineering, or a related field. They don't even have the equivalent of a single four-month community college programming course. If we're lucky, they've read a single book about web development using Ruby on Rails. (This is ignoring their other serious flaws, such as the complete inability to dress or act with even a minimal level of professionalism; I've interviewed some of these hipsters while they're wearing t-shirts with dumbass sayings on them, and fedora hats.)

      Now, having been in the industry for years, I can see right through these people. When they get past HR, they don't get past me. But I can't be everywhere. I've worked with a few organizations lately where the people making the hiring or purchasing decisions in the past didn't know better, and now these organizations have ended up with their very own Ruby on Rails disasters.

      The Ruby community may not realize it, but they're getting a very bad reputation in the industry. It's nearly as bad as the reputation that the PHP and JavaScript communities have now. But this is exactly what's expected to happen when dealing with programmers who do shitty work in the first place, or who think it's perfectly normal to write unmaintainable code, or who think it's acceptable to job hop 3 or 4 times a year, or who can't work in a professional manner, or who deliver one under-performing and costly software disaster after another.

      At more and more places, "Ruby" and "Ruby on Rails" are becoming synonyms for "costly disaster". That's not the kind of reputation that a programming language or a web framework can have if it wants to survive and flourish past the short term. Maybe the people in these communities don't realize it, but they're losing trust at an alarming pace.

    • In the domain of language in which Ruby plays, I'd say Python has by far the brightest future.

      Some graphs from google trends: ruby programming [google.com], python programming [google.com] and php programming [google.com]. Which one of these things is not like the others? (Hint: Python).

      TIOBE data [tiobe.com], questionable as it is.

      Search for jobs at LinkedIn:

      Ruby: 112 results
      Python: 5,151 results
      PHP: 3,046 results

      And the "programmer perception" survey [berkeley.edu] Berkeley did a while back (that I think was covered at Slashdot). Check out the results for
      • TIOBE is not a particularly good metric, IMO. PyPL [google.com] (which counts search results for "X tutorial") is a better indicator of which language is popular to learn today (which, quite obviously, translates to its popularity in short term).

    • by Zarf (5735)

      Ruby is standing stronger than ever [google.com].

      By this metric Java [google.com] is still kicking everyone's butts. Also... *all* programming languages are "dying".

      I've been around the block enough times to know that if you want to survive as a programmer you had better damn well learn to program. And not in just one language, you need to know a survey of language types. Ruby is just one type in the same category as Python and Javascript. If you really want to survive 20 years as a programmer (like I did) you need to branch out more.

      Now, you kids get off my lawn.

    • are you sure those people aren't searching for jewels or JFK assassin killers?

    • by hairyfeet (841228)

      Well hell if THAT is the only metric that matters I need to brush up on my VB as its doing great [google.com], right up there with Python as a matter of fact.

      That said maybe I'm weird but I never understood the "Is X dying" and "Is Y gaining in popularity" I mean who gives a shit? Does it do what you need it to? Can you get your project completed using it? then STFU and use the dang thing, quit acting like a Valley girl chasing trends already! I mean you don't see the engineers going "ZOMFG my VHDL is as out of fashio

    • I would wager the amount of google queries only shows how many "questions" you have.
      Which leas to the question if Ruby is indeed such an easy language everyone claims ;D

    • Now add Perl to your graph...
    • by hutsell (1228828)

      Long answer: a better indicator is how many Google queries for the respective languages are issued. And those suggest that Ruby is standing stronger than ever [google.com]. Ruby is more than just Rails. And just because there is yet another web apps framework, it doesn't mean that the other ones automatically lose traction.

      The Google trends supplied in your link used generic search terms, seriously skewing the results inaccurately about programming languages. Stuff about reptiles, famous comedy acts and things such as an infamous Italian scandal (and whatever else) were being included. By replacing the display with terms specific to programming, this version showing trends for searches about programming languages in Ruby, JavaScript, PHP, Java and Nodejs [google.com] should show something a little more meaningful.

      Since the summary is mo

  • by Anonymous Coward on Tuesday December 24, 2013 @03:17PM (#45777737)

    It is now official. Netcraft has confirmed: Ruby is dying.

    One more crippling bombshell hit the already beleaguered Ruby community when IDC confirmed that Ruby market share has dropped yet again, now down to less than a fraction of 1 percent of all languages. Coming on the heels of a recent Netcraft survey which plainly states that Ruby has lost more market share, this news serves to reinforce what we've known all along. Ruby is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent programmers survey.

    You don't need to be the Amazing Kreskin to predict Ruby's future. The hand writing is on the wall: Ruby faces a bleak future. In fact there won't be any future at all for Ruby because Ruby is dying. Things are looking very bad for Ruby. As many of us are already aware, Ruby continues to lose market share. Red ink flows like a river of blood.

  • by thule (9041) on Tuesday December 24, 2013 @03:24PM (#45777789) Homepage
    Chef and Puppet are huge in DevOps. It seems Ruby has found its niche.
  • by stox (131684) on Tuesday December 24, 2013 @03:24PM (#45777793) Homepage

    Now people can spend much more time actually writing applications than writing supporting infrastructure.

    • by Xtifr (1323)

      I think that's as bad of an oversimplification as the original thesis. But it certainly raises an important issue the submitter seems to be ignoring. For a highly modularized system, a lack of contributions to particular modules may well simply indicate that those modules are mature and don't need a lot of additional contributions any more. To really get a feel for the health of the overall ecosystem, you have to take a broader view.

  • by Billly Gates (198444) on Tuesday December 24, 2013 @03:24PM (#45777799) Journal

    Node.js invents threading/processes and is webscale [youtube.com].

    The best part is once you start coding it you will find yourself with a neat trimmed beard in designer plaid in a hip coffee shop listening to music not even out yet with 2 georgous ladies by your side giggling and being turned on by your most awesome code that is on your laptop screen.

    • with 2 georgous ladies

      Does that mean two "ladies" both named "george" who are presumed to be into cross dressing? No, thanks.

    • by Animats (122034) on Tuesday December 24, 2013 @04:26PM (#45778215) Homepage

      But it's web scale.

      The event/callback/state machine model is a pain to program in, but at least you don't have race conditions on shared data. Also, now that most Javascript programmers are aware that the language supports closures, callbacks aren't so hard to code properly.

      The classic problem with threads is that the usual locking primitives (which are almost always variants on the POSIX primitives) are treated as an OS object, rather than part of the language. For most languages, the language has no idea of which locks lock what data. Ada gets this right, but the Ada rendezvous is clunky. Even Go gets this wrong. (See the endless discussions of "is this a race condition?" in the Go newsgroup.) So race conditions are common in threaded software, and a cause of random failures.

      Practical problems with threads include crappy implementations of lock primitives that make a system call even in the non-blocking case, the cost of fencing on superscalar CPUs, and poor scheduler coordination between context switching and message passing.

      Most of those issues are way too theoretical for the average web programmer. It's better that they not have to think about them. There's a lot of web code to be written and we don't want to waste the good people on it.

  • Ruby as a language is progressing well and Ruby 2.1 will be out soon.

    Ruby gems is still active.

    Just because it's not getting all the buzz from the young kids doesn't mean it's dying.

    • Just because it's not getting all the buzz from the young kids doesn't mean it's dying.

      Ruby is not C. Ruby was born amidst a slew of toy languages, getting all the buzz from the young kids. Once that buzz died down, and the kids moved on to newer fad languages, and without a generation of seasoned programmers extolling its virtues, Ruby died.

      Ruby isn't dying. It's already dead.

      • I view Ruby as Perl evolved. There is a need for scripting languages and both Ruby and Python do a good job filling that niche.
        • See, that's the thing. Perl isn't dead. Perl is still used extensively in system administration and for quick prototyping and proof-of-concept work. Python is still alive and well in the sciences as a supplement to MatLab and other similar tools. Perl and Python have both just about vanished from the web, though, as other server-side scripting tools have become more prevalent. This same tide that displaced Perl and Python from their traditional stomping grounds has also displaced Ruby. However, Perl and Pyt
          • Perl is still used in sysadmin, however Ruby is gaining ground at Perl's expense in this area.

            Python is being used in science by the new post docs, but fortran, matlab, and IDL still reign supreme. (I like python because it's way cheaper than IDL or Matlab). Perl actually has a larger share of science use than Python. Python is replacing Perl as a glue language for science with Fortran and C still do the heavy lifting.

            Ruby is also being used in science. Ruby + R when plotting is required, otherwise Ruby (

      • by iggymanz (596061)

        that's funny, you think your little part of the world is the whole?

        Ruby is quite popular in asia, used in huge projects.

  • Node.js (Score:5, Interesting)

    by thammoud (193905) on Tuesday December 24, 2013 @03:31PM (#45777851)

    We had to swallow a dagger and use JavaScript on the client as it is the only game in town. Please someone, enlighten me, why would I use this horrific language on the server side? What exactly am I missing? What is so great about Node.js that warrants having to deal with JS.

    • Re: (Score:2, Interesting)

      While you and I, as programmers, have an innate hatred for JavaScript, you can't overlook the hoards of "web developers" whose only experience writing code entails JavaScript.

      What's great about Node.js is that it doesn't warrant hiring actual programmers.
      • I assume that when you say "writing code", you mean, "cobbling together cargo cult code snippets invoking jquery/prototype that were harvested from the first Stack Overflow result that Google crapped out." Your version is definitely more concise, though.
        • by tibman (623933)

          lol, like you don't do that for C#? The language does not make the programmer.

    • Well, for one, you can have the same single-threading benefits you have in the browser, now on the server! Cooperative multitasking like in the old days! It will make you forget what threads were invented for in the first place!

    • Re:Node.js (Score:4, Interesting)

      by countach74 (2484150) on Tuesday December 24, 2013 @03:56PM (#45778019)
      JavaScript is rather misunderstood. It does, indeed, have issues--perhaps more than other languages (I'd say certainly more than say, Ruby or Python). But it has merits as well that most people overlook or simply don't know about. It is, for instance, very expressive. Particularly in the server-side programming realm, NodeJS has a few advantages to it that most other languages / frameworks don't (or require more difficulty in implementing), such as:

      1. Naturally asynchronous, NodeJS allows vastly more I/O than a similar threaded solution. Need to implement long polling for 2,000 concurrent users? Not a problem.

      2. The ability to share libraries and other code effortlessly between server-side and client-side applications.

      Some of the down sides to NodeJS are that, well... it uses JavaScript. Seriously, though, it could be worse: it could be PHP. JavaScript really isn't that bad, once you actually learn the language. I hated it until fairly recently because I didn't really understand it. Now that I've spent some time learning its intricacies and quirks, I am much more productive with it. I can even enjoy using it. Would I prefer using Python? Absolutely. But it's really not so bad.

      Moving forward though, I think one of the biggest problem with JavaScript in general is that we have far too many people who know just enough JavaScript to be dangerous that trying to establish high community standards will be very, very hard. In fact, one of the reasons I like Python so much is not that Python itself is all that great (it, too, has issues), but rather that there are countless excellent, well maintained, well designed libraries available. The same is simply not true for JavaScript in general.

      • by radish (98371)

        Naturally asynchronous, NodeJS allows vastly more I/O than a similar threaded solution. Need to implement long polling for 2,000 concurrent users? Not a problem

        And it's not a problem in any other decent server side language either. Async/Completion Ports for .NET, NIO/Mina/Grizzly/etc for Java.

        The ability to share libraries and other code effortlessly between server-side and client-side applications

        I'm struggling to understand why you'd ever want this (assuming a web application, which is a fair assumption

        • And it's not a problem in any other decent server side language either. Async/Completion Ports for .NET, NIO/Mina/Grizzly/etc for Java.

          But it is in Ruby, to my knowledge. And many other higher-level languages.

          I'm struggling to understand why you'd ever want this (assuming a web application, which is a fair assumption as you're talking about JS). Your business logic lives on the server, your presentation logic on the client - and never the twain shall meet. The only thing I can really think about is data type definitions, but JSON does a good job of simplifying that (and something like GSON will deal with the conversions). Now I have wanted to share code between server and client in a rich client application, but in that case I could build both sides in either .NET or Java and be perfectly happy.

          Yeah I'm mostly thinking pseudo classes and things like that. Say, a custom date/time library, etc.

    • We had to swallow a dagger and use JavaScript on the client as it is the only game in town. Please someone, enlighten me, why would I use this horrific language on the server side? What exactly am I missing? What is so great about Node.js that warrants having to deal with JS.

      Because web developers think they invented threading [youtube.com]. They like node.js because they can do block/non block I/O and asynchronize programing and can write something hip called events to manage them with a new technology called a scheduler.

  • by PNutts (199112) on Tuesday December 24, 2013 @03:41PM (#45777911)

    Damit Jim, I'm a doctor, not a developer in a dynamic, reflective, object-oriented, general-purpose programming language that supports multiple programming paradigms, including functional, object oriented, and imperative.

    Thank you, Wikipedia.

  • Short answer: yes. (Score:4, Insightful)

    by hessian (467078) on Tuesday December 24, 2013 @03:56PM (#45778027) Homepage Journal

    Trends always die.

    All-purpose languages that adapt over time are better tools to learn.

    You learn more in depth, instead of having certain tasks be very easy.

    This is similar to the trade off between wizard-based interfaces and actually knowing what you're doing with an operating system.

    • by xtal (49134)

      It amazes me the utility and run I've gotten out of learning C and C++.. decades go.

  • Dear Ruby: Please leave Chef behind and go and die in some dark corner. Take rails with you. Thanks.
  • Clearly I am not in "the web world" and I am seeing this question from an external viewpoint. But I never really saw anybody exciting about ruby or using ruby or praising ruby except one single phd student who was using it to make his experiments repeatable and automatically logged. Sure there is an occasional article on a new version of ruby, a flaw in ruby-on-rails. I heard people talk a lot about PHP, about Python, about javascript, to do pretty much anything. But quite frankly I never hear about ruby. A

    • It must be your scope of work that you haven't heard of it as a option for a given project, or that no one uses it.

      I'm often put in the architect position, or at least, the seat right next to them, and Ruby has frequently been brought up as a contender. It's not being brought up because it's especially good, but rather, it's evangelists, while small in number, tend to be loud in voice. It's what I call a 'toy language', in that it's fun to play with, and the kids especially seem to like it, but very few p

  • by JoeyRox (2711699) on Tuesday December 24, 2013 @05:01PM (#45778513)
    :snicker:
  • by Exitar (809068)

    Has Ruby really been alive?

"Bureaucracy is the enemy of innovation." -- Mark Shepherd, former President and CEO of Texas Instruments

Working...