Ruby has entered final maturity. It will be in that phase until such time as it really does die, which could well be 10-15 years. Or more, though, honestly, I doubt that in 2028 we'll be considering Ruby anything more than legacy code... that's not because of Ruby itself, but rather the language category it is in. I expect we'll be looking at Python and Perl the same way.
Oh, and kudos for running numbers before simply writing the "Ruby is dying!" blog post!
Edit: removed "update for a security patch" because it's just updated.
Edit: to be fair, this is a common situation with many similar solutions.
It's true that if you're running a _very_ old version of Rails, you may not get a patch. There are community projects like Rails LTS that help with this, though.
I have found no compelling reason to switch, and lots of annoyances that don't seem to exist in Perl.
If you learn C well, everything else(C based languages) look the very same.
Perl enjoys that first movers advantage.
Python isn't so bad, decorators and importing is all very swanky. I find that in general though things tend to be less elegant than intended but the delusion of perfection is maintained. I oppose Python's core philosophy and having used a bunch of Django, that also soured me a bit.
That said, I suspect there are fewer people picking up Perl for the first time for a project these days. My experience with it has always been driven by some degree of "legacy"--someone on the team has experience with the language, and has leveraged CPAN to solve problems. Perl is still my go-to "glue" and tooling language, but that's just because what I know. Would Ruby work? Yeah, probably, but I've not found it to be worth it to learn that language yet.
Another one, that is huge : YouPorn (itself) is using Catalyst. YOU-PORN!
In my opinion, the main Perl's strength is the cpan.org :
Stop reinventing wheels, start building space rockets
The Comprehensive Perl Archive Network (CPAN)
currently has 128,529 Perl modules in 28,883
distributions, written by 11,129 authors,
mirrored on 266 servers.
The archive has been online since October
1995 and is constantly growing.
This may be true for Ruby to some extent.
But Python as a design goal aims to provide as little power to the programmer as possible. In fact, the Zen of Python says almost anything that comes in the way should and must be sacrificed to achieve readability.
One can probably write a book on why one must use Perl. In short, nothing really gets work done as Perl does. That one fact hasn't changed since the past 26 years of Perl's existence.
Yes, what about them? First time I heard of them, and I frequent more than 5 tech sites such as HN.
>If it's just used in legacy code, why are there still healthy frameworks being produced
Because it's very easy to produce a web framework, everybody and his dog has created one (that, or a blog engine). That doesn't make those freameworks "healthy").
Vast majority of the programming community doesn't have to ever deal with a HTML tag ever.
Drop me a line Moto7451, I'm always interested in meeting local (Perl) hackers.
However, more to your point, there's legacy C and Java code, but that's because those languages have evolved heavily in their time, so late 90s Java looks little like modern Java, and techniques used in C in the 80s would get you laughed at today.
Hell, even in my main language of work, C#, the difference between most code just 4 or 5 years ago and "modern" C# is vast.
* Python - As a programming language for scientists and researchers, replacing Matlab and kin.
* Go or Rust - A well-designed, modern language, easier to use than C++ but almost as fast, for enterprise applications or video games. Not sure about Google, but I hope Mozilla will still be around in 10 years.
* Lua? - Not sure about this one... but it fills a niche -- extremely compact scripting language.
* C - still used in system-level programming
* C# - C# is replacing Java as the OO language of choice for big enterprise systems.
I'm skeptical of this one. C# requires Windows Server or putting up with Mono's shit. The former sucks; the latter isn't great either. I'd bet that iterations on Java, as well as other JVM languages, will probably retain a significant edge long-term.
C# is held back by windows. I know there is mono, but enterprises aren't going to bet on mono. So I have to disagree with that.
"The enterprise" (for the most part) isn't held back by Windows. That's just reality.
Or, rather, much of "the enterprise" is committed to being held back by Windows, so a language being tied to windows doesn't hinder enterprise adoption.
The language is small, it's very fast as scripting languages go, and I've heard it's easy to integrate it with C and other languages. On the other hand, it has kind of weird syntax, breaks a lot of conventions (i.e. arrays are 1 indexed), and it's not a massively well known language.
Unfortunately I imagine that Google has enough money to be around at least 20-30 years.
C++ I can see going either way; it is a freakishly complicated language (and getting more complicated with every standard that comes out) that IMHO was primarily kept aloft by being the "default" language in Windows for a very long time. I expect Rust will be most of the way through eating it alive in 15 years. Or something like Rust, but Rust is looking pretty solid. And if you want a multithreaded systems language... and you will... I suspect in practice it's going to be an order of magnitude easier to program in than C++ in another three or four years. Maybe Rust will even be eating C. (About damn time!) Someone will probably be writing an OS kernel in Rust. Possibly one that is driver-compatible with Linux, or even just straight-up a Linux-compatible kernel.
If Google doesn't drop the ball, Go will probably be mature and still going, and probably the primary reason why Ruby and friends are considered legacy code. Go even today very nearly replaces the scripting languages in flexibility (though definitely not quite), but brings back stronger typing and better performance. A few more tweaks to it over the next 5 years and it'll be hard to see why I'd start a new project in a "scripting" language. (Part of the reason I think this is that I observe that in the past 15 years, no language has penetrated into the A-list without some sort of major corporate backer. While there's plenty of other possibilities from a technical point of view, and while Google is not very aggressively pushing Go, I still think it's more support than any other language has or is likely to have in the near future. Even if they just passively continue to do little more than employ the authors, this is likely to continue floating up the ranks.)
And I still sort of expect something to come up that is not Haskell, but is closer to Haskell than anything currently existing. Or possible Haskell simply keeps plugging along and manages to become a very solid B-list language. I doubt it'll ever break into the A-list "nobody got fired for choosing C/C++/Java/C#" level of popularity, but it might settle firmly into where "it's pretty hard to get fired for choosing Python/Ruby/PHP" is today. (It's brushing B-list status now, but it's got a ways to go before I'd call it solid B-list.) I also think there's a good chance it will acquire a reputation as being the tool of choice for tackling truly complicated systems. (Though Rust will eat into the bottom end of that a bit too, they're currently retreating from some of the tools that Haskell has that may allow it to acquire this reputation. I think Haskell will still retain a strong advantage here.)
And finally, some sort of wildcard. 15 years ago I doubt anybody would have predicted Haskell being where it is now, even Haskell users (if you can even call it the same l. New languages shall continue to bubble and froth, but at least one and probably two will either emerge from the froth and become a B-list language. Probably at least one of them will be a aggressively "practical" language that will be a reaction to the success of "excessively-academic" Clojure, Scala, Rust, and the Haskell-like I hypothesize above, and follow a hype curve very similar to Ruby or Node.
It occurs to me I'm looking more like 10 years into the future here than 15. Oh well. Close enough. I'm also well aware I'm just talking out my ass; I completely expect to look back and laugh at this in 10 to 15 years. Oh well again.
Ruby's DSLs for writing things that Web application's need (serving HTML) are bar none the best. If I'm writing something that is serving HTML, I'm using Ruby all day, every day.
If I had to then pick a replacement, I would argue for Dart. Dartlang has a much stronger set of novice documentation, nodejs-like magic of running in client and server, but advanced Google mojo like support for SIMD. All Dart really needs is Chrome support and a decent "Rails" clone to popularize server-side development. We're a few years off, but Dart could be quite exciting. Or it could end up running on the JVM like everything else :p
It's not "replacing Rails", it's replacing new projects in what are today scripting languages (Perl, Python, Ruby, PHP, etc.).
I see fewer people talking about Dart than I see doing things with Go. That said, I did finally beat Google Trends into producing , which is interesting. It was hard to convince Trends to show Dart as growing as quickly as Golang, though, so there may be a selection effect (of the several graphs I produced with Dart well behind Golang, this is the only one that shows them even tied), and it still shows Dart as tied with Go, and Go's growth being more steady. I'm still not sure Dart is growing like Go is.
I suppose I should point out that the predictions were my best guesses about what will happen, and do not simply reflect what I "want" to happen.
I'm a bit more flexible when it comes to trying to predict the future than my posts indicate. I'm just offering an alternative hypothesis: Dart has many more screencasts and supported libraries from Google, including Angular.dart than Golang ever had, and it's only just hit 1.0. Golang has been fantastic for me to develop with, particularly on Google AppEngine and it's true Dart hasn't hit server-side popularity yet. But if we're predicting the future, based on JS and node.is alone, I'd suggest Dart has plenty of room to gain popularity quickly.
For me, I was making broad predictions. No matter how exciting the web client dev is, it is and will remain still a niche, and Dart faces a huge challenge in the next 5 years as asm.js will relatively suddenly introduce it to competition from every other mainstream language in existence. Dart probably won't "die" for a while, but I'm not sure it won't end up "just another" one of the enormous pile of languages that it will be possible to do client-side programming in.
The real question is when will Google add development alternatives to Android? Chrome's nice, but it takes a mobile platform to sustain an ecosystem of client-side developers these days. Perhaps Chrome-on-Android will eventually become the new PhoneGap?
There are two or three of these, at least at the stage where kmain is Rust code. I'd be really excited to see this develop further.
I just don't have time for ever project I'd like to do :/
In other words, this is an extreme statement of confidence on my part that Rust is very likely to succeed in their goals of being a true system language replacement. (Contrast this with Go, which initially started out saying it was going to be "system" language, but they've clarified they mean something more like a serious application language rather than something you'd write an OS in. "Nobody" is going to write a kernel in Go.)
Rust looks promising, but it's way too early to tell if it can really replace C/C++.
Even the wrong tool for the job is a nice choice if someone's already done the work of making a square peg fit a round hole for you.
And more people to hire, or to hire you, as well as books, mailing lists and so on.
Economists call this "positive network externalities", where the value of something increases with the number of people utilizing it.
That's the most overstated claim in programming. LESS is the "right tool for the job" when the job is styling web pages. Ruby is a general purpose programming language, the jobs it is good for is everything not covered by DSLs like LESS, the same as all other general purpose languages.
I question that. Ruby is very slow, dynamically typed and suffers from scaling challenges because of its multithreading support.
I think Ruby is increasingly falling into a niche: prototyping. Get a prototype up and running in a few weeks and once the proof of concept is established, switch to a statically typed language on the JVM.
Ruby was slow (still is), but that trend is changing. More and more effort is put into speeding up and modernising Ruby in general.
It might have only begun to mature, but it's definitely getting a there.
Rubinius is a lot faster than MRI and has proper multithreading support. There is also JRuby, which runs on JVM.
It's really a question of how and what you run. And yes, the JVM is one of those options.
I think there is a minimum threshold to this. I support a large application written in an extremely obscure language (it's basically me and 5 other people on an old yahoo mailing list that make up the entire community). It is terrible. No unit testing frameworks, no http framework for rest calls, no decent UI templating, and on and on. 100% of functionality that I need comes in the form of calls to command line tools.
Obviously, Ruby is way past that threshold, so I do not disagree with what you said at all, but just wanted to point out there is a limit. I would not write a new commercial application in any language today that did not already have strong package system. As one person, you can write a few essential modules that you need, but you cannot write all of them.
As to the 5 people... yep about 5-10, and my company employed a few of them. The rest are academics. The 'bus-factor' was pretty high before we switched off of it.
Very wrong. There are languages that I believe I would be very productive in, but can't justify the time investment because the community is so small that the related tools/libraries/frameworks aren't there.
On the other hand, if you are learning a language or platform in order to expand your capabilities as a thinker and problem solver, then community size is less of a consideration.
I know just the little bit of Scheme and Haskell has transformed how I think and my thought patterns. I can say the same about learning to play Go (the game, not the language).
Now, whether you get anything out of it, that's up to you. It's not really about learning a language that fit your mindset so much as learning a language to change and expand one's mindset. If you expect a language to fit your mindset, then you're unlikely to get anything out of it. In which case, definitely stick with the popular languages with a lot of community support. That has a pretty good ROI too.
After Node will stop being popular and "hip" author will probably make a new post saying "Is Node Dying?".
That said, I find both Python/Django and Node.js both more productive than Rails for quickly building API-driven web-apps. More so this has to do with Rails, which has a number of warts and a tendency to require excessive configuration for all its pretty much patently false 'convention over configuration' spiels, than it does with Ruby.
If there's a problem with Ruby, it's the inseparability of it and Rails. As things like node make using non-JS languages server side less appealing, use of Rails will decline, making Ruby decline.
The main reason this hasn't happened is that there's not a standard groupthink-do-it-all toolkit for building things with node yet.
And even when it does happen it will take years and years to go away. Just look at PHP.
I'm going to go ahead and say it: Ruby will be the new PHP...
And yes, I think it's fair to assume that Ruby usage is vast majority tied to Rails.
such as ?
Rails has plenty of warts but models still live in /app/models, classes are named after tables and all CRUD routes are defined with a single two-token line.
You are probably forgetting to consider what the world was like before this.
That said, as a pro-Rubyist...well, I don't find much comfort in the OP's spurious assumptions about what the data can show. However, for those who think Ruby's time is limited or otherwise hate the language (or more specifically, Rails)...what do you think will take its place? Ruby seems popular because of its readable syntax...which is also a factor in its relatively slow performance...do you see an even more human friendly (and inefficient) language taking its place? Or do you think such a niche need not be filled?
That Ruby is so great for DSLs...I would hope that it can stay in that function as one of the better glue languages we have.
Not a bad spot to be in if I may say so.
I would like to also point out the title of the post is misleading, as the findings are exactly the opposite.
Ruby dropped 3 spots from this time last year (currently #13); if it is dying, it's dying slowly.
For my work on the JVM, Scala in comparison is way down at spot #31; Groovy #47, and Clojure doesn't even break the top 50.
Meanwhile F# is kicking some serious azz, soaring 27 spots in a single year to #20, impressive.
Ruby should be just fine for the next several years, assume will drop down into the 20s as the static typing + FP movement takes root in the enterprise.
2014 should be a fun year for the JVM: Java 8, Scala 2.11, a possible Kotlin release, and whatever Groovy and Clojure have planned.
Groovy's roadmap just added version 2.3, featuring "_Traits_", which were actually originally announced for version 2.2 , but were delayed so Codehaus could get a release of Groovy out the door in time for selling seats to their annual December GrailsXchange conference in London.
In June last year, Codehaus/Pivotal had also announced a new meta-object protocol for Groovy version 3.0  to come after version 2.1, but that was postponed early this year to make way for version 2.2. I don't think Groovy really has anything "planned" as you put it, rather they're reacting to external conditions.
They can't really tell the difference between Ruby(The stone) and Ruby(The language). Or Python(The snake) and Python(The language).
I definitely think MRI will die, and Ruby will live on in the JVM. I've been really impressed with JRuby and the advances they have made on that project.
Plus you also have projects like RubyMotion and the promising Opal(Ruby to JS).
I love the idea, but it seems few are interested....
I was forced to learn Ruby while at Aardvark, as well as the Rails and the Agile process.
It was true today as it was then; Ruby, Rails, and Agile are absolutely useless for real data science and machine learning, and this is what companies need to move forward.
Indeed, to bring machine learning tech to the Aardvark team, I had to fight tooth and nail against the Rails consultants and the Agile process guys.
Ruby is a useful gateway language for learning other modern scripting languages such as python, lua, and scala
I agree that Ruby is now legacy technology.
Let me be clear; I use it all the time. It is useful to build stable projects based on solid ideas, and I use it for dev ops, for crawling the web, and for making simple DSLs. Chef is very good (compared to, say, Ansible) , and the Bundler deployment system is quite nice. It is easy to build web endpoints in Sinatra, and the Nokogiri gem is a pleasure to work with compared to, say, java JSoup.
But Ruby is not moving the needle forward. It does not even have a decent NumPy-like module, which makes it completely useless for modern back end work in data science, machine learning, and the real things companies need to generate revenue
Rails is a good example of being overspecialized. They are so good at web programing circa 2007 that the future passed them by.
Python. Lua. Scala. Closure. These are the future.
EDIT: This one is maybe more accurate (w/ 'programming' as selected category) and it shows that interest is roughly the same on average:
I was using Ruby as my main language for 3 years before I switched to first Coffeescript and then Scala now. Personally I prefer the simplicity (a function is a function) of Coffeescript and the richness (so many things to fool around) of Scala over Ruby.
The popularity of languages don't die over the course of a couple of years. Projects with legacy code rely on them and maintenance of their libraries. And legacy code is very very hard to kill.
If the interest is in finding out the trend of the "favorability" of a language, it might be more accurate to survey how many green field software products(not libraries, which could be driven by the need of improving some legacy code) are choosing it. Unfortunately, such survey is more expensive to perform, and might be close to impossible to perform retrospectively to understand the trend. Given the fact that the "popularity" of a language isn't that important, the favorability is probably even less, such survey is probably hard to justify.
Ruby's best days are still far away.
Additionally, I doubt gem releases correlate with language 'vitality'. Fewer releases may simply indicate library stability.
That and command line apps in ruby, well there like perl with cpan modules, sheer pain to manage across systems. Versus static link in archive files and make a package.
If you want to find out if TV sales are declining, you don't compare against the 1950s.
jruby and rubinius close the performance gaps. (This is an arguement for only knowing one language.)
also most gems in all areas are good enough already