Is Ruby Dying?(jmoses.co)
jmoses.co
Is Ruby Dying?
http://jmoses.co/2013/12/21/is-ruby-dying.html
158 comments
This is it. I'm blown away by how productive I am with rails now. A couple of weeks back I replaced an entire backend, complete with an oauth provider, record versioning, caching etc. and it took 4 hours! And all done with the usual TDD etc. This is all thanks to the gems that are available. Most of them are 2nd or 3rd generation, they're focused, battle tested and well documented. It might not be the right tool for every job but it's damn good at what it does. If the noise has died down it's because we're busy knocking out great apps.
Wait until you have to update your rails and all your gems are no longer compatible.
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.
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.
The Rails team generally provides patch files for security updates, specifically so that if upgrading Rails is not possible for you, you can just patch your Rails. Especially thanks to Bundler, it's quite easy: http://blog.steveklabnik.com/posts/2012-10-04-run-rails-with...
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.
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 think it's fair to say that you have to rise with the tide a bit if you're going to use rails. The projects I work on tend to be continuously developed though so this has never been a pain point.
I think Perl has already reached the state where it's mostly used in legacy code, at least for web development.
What about Catalyst? Or Mojolicious? Or Dancer? If it's just used in legacy code, why are there still healthy frameworks being produced (granted, these aren't as popular as Rails, but, Perl on the web is hardly in legacy mode)?
I personally haven't seen any new code being written in Perl during either my time in England or in the Bay Area. I don't really see a reason to use Perl when there are languages like Python and Ruby out there with easier learning curves and which are just as, if not more powerful (would be happy to learn some good reasons, though).
I am in Manchester. I write new Perl code. Python is Perl with a little nicer syntax and a shitload of baggage from overly opinionated people. Ruby is Perl with a little nicer syntax and no other advantages.
I have found no compelling reason to switch, and lots of annoyances that don't seem to exist in Perl.
I have found no compelling reason to switch, and lots of annoyances that don't seem to exist in Perl.
Following this logic, every language is Perl with a bit of this or that. Perl was one of the first of the kind, but people saw obvious problems with it and so they innovated with 'little nicer syntax' or 'little better object system'. You might not want any of this, but you can't deny most people are happier with Python or Ruby.
I'd say it's more like Perl is every language with a bit of this or that. A sufficiently "skilled" Perl hacker can write everything from bad C, to bad Lisp, to bad Fortran, in Perl -- and most certainly can write plenty of bad Perl in Perl, too. It's writing good Perl that's hard.
You're not wrong, but I wrote that from my perspective, as someone who primarily writes Perl and needs a compelling reason to switch. Obviously someone who was writing code pre-Perl will probably see things a different way.
This is true for all language that do things right the first time.
If you learn C well, everything else(C based languages) look the very same.
Perl enjoys that first movers advantage.
If you learn C well, everything else(C based languages) look the very same.
Perl enjoys that first movers advantage.
There was a talk by Guido Van Rossum effectively saying that Perl, Python and Ruby are the same language.
I'm actually a big fan of Perl, but your characterization of Ruby is wrong. Ruby is Perl with object-orientation first, nicer syntax is a minor detail after that.
It's the only major detail to me, because I can do the majority of what I would use in Ruby, in Perl. Nicer syntax is something I can't do though.
If you can constrain yourself a reasonable OO system in Perl why can't you constrain yourself to a nice subset of the syntax?
I can, I can deal with overly verbose maps or shifting variables off @_ but Ruby provides some similar features to Perl 6 right now. That is an advantage on its part. It's just not compelling enough to make me switch as Perl can do most of the rest just fine.
See the CPAN module Moops.
I'm thinking more of things like the p6 arrow. Moops is part of the first part, things I can already do in Perl that are in Ruby.
Ruby also now has a VM, which people may or may not find more useful. I for one prefer Ruby 1.9.x to 1.8.x.
If Ruby has nice syntax then Smalltalk should be the syntax of the Gods ;)
The language of the Gods is clearly Lisp. Unfortunately it's such a pain to work in that most of the time the Gods just use Perl anyway. Oblig. XKCD: http://xkcd.com/224/
Remember we are comparing to Perl ;)
Having written some Python I agree. Having written a lot of Ruby I disagree.
Can you elaborate on Python's baggage? I'm simply curious.
I wouldn't characterise myself as any sort of expert so really I'm just talking about minor things like ternary operators, ugliness with super, scoping, the annoyance of PEP8 being overly specific etc. Just decisions taken for the sake of 'correctness' that end up being annoying.
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.
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.
By this measure, C, or C++, or Ruby must be dead, since I've not seen any new code written in it during my 13 years in the industry.
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.
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.
I see C and Ruby code being written every day in San Francisco.
So the bellwether of a language's health is whether it is being used in San Francisco?
To be fair I see C and C++ used all over the place. Pretty much any game out there has at worst a 50% chance of being written in C++. C is less common, but is still used quite extensively in the open source world. Most devices with firmware are written in C (or at least their drivers are).
Just ask http://www.builtinperl.com/ for the reasons why. For exemple don't you know that DuckDuckGo is using a lot of Perl ?
Another one, that is huge : YouPorn (itself) is using Catalyst. YOU-PORN!
In my opinion, the main Perl's strength is the cpan.org :
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.Actually youporn, rewrote all their code in PHP:
http://highscalability.com/blog/2012/4/2/youporn-targeting-2...
http://highscalability.com/blog/2012/4/2/youporn-targeting-2...
Damned ! Here is an information that should be uploaded to Wikipedia.
>>easier learning curves and which are just as, if not more powerful (would be happy to learn some good reasons, though).
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.
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.
What does power represent to you? Simplicity and readability offer power as far as I'm concerned.
Just because Perl can parse line noise, doesn't mean you can't write readable code. I have seen very unreadable code in Python.
>What about Catalyst? Or Mojolicious? Or Dancer?
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").
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").
NYC financial firms are starting new projects all of the time where Perl is the main tool for feeding information here from over there.
For any categorical statement like that, there will be hold-out niches where it doesn't apply yet. Hell, I'm sure there are some banking types who are starting new projects in COBOL.
Except that programming is such a large domain, you could easily classify web development as a niche itself.
Vast majority of the programming community doesn't have to ever deal with a HTML tag ever.
Vast majority of the programming community doesn't have to ever deal with a HTML tag ever.
I work at a Perl based startup and we're writing new code and designing new systems all the time. There seems to be quite a few Perl shops in LA though most of them have been around for a long time.
Perl's my mother tongue (started in bioinformatics) but I've been doing a lot of Ruby at my current gig in LA. That being said, I miss Perl's syntax and autovivification. I did a hackathon project with Perl at work, and my punishment for winning was porting it to Java for production.
Drop me a line Moto7451, I'm always interested in meeting local (Perl) hackers.
Drop me a line Moto7451, I'm always interested in meeting local (Perl) hackers.
What do you reckon could not be legacy code in 15 years? C family, Java, maybe Erlang?
I expect the JVM to still be going; at least one of Clojure or Scala will probably continue growing for a long time, and there's room for both. It's also possible another Algol-esque language that isn't Java, but is syntactically closer to Java, making people more comfortable, will arise. At some point one of them may even become the "primary" JVM language, with Java hanging on as legacy, but due to the fact Java just compiles to the JVM, there won't be any reason to get rid of it, as the maintenance effort is virtually 0. I expect C# to probably still be going. I'm not sure anything can actually kill C, even though something really should.
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.
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.
I like Go, but in my opinion it is not an appropriate language for building web applications. It makes for great sub-components of a larger stack which are focused and do relatively low-level tasks (networking, file serving, caching, etc.). It is also great for scripting where you need easy out-of-the-box concurrency.
This times a million. I think Go is awesome for a little bit of systems programming but I'd pull my hair out trying to make a robust Web application with it. I feel the same way about Node.js. I wouldn't use either of these for a public facing HTTP application but if I needed some hyper performant internal system using RPCs then I would use them.
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.
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.
Have you given martini a try?https://github.com/codegangsta/martini
For a Google-backed language to replace Rails, Golang has less of a shot IMHO. Mainly because the popularity of Rails stemmed initially from TextMate in the original screencasts. It'd be silly to say that's all that mattered so I'm going to merely strongly imply that without additional books or cookbooks, screen casts, etc. it's hard to see Golang taking off in a community that isn't already invested in learning it. Those looking for more stability will pick a JVM-based language, which includes JRuby, and call it a 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
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
AFAIK Dart still does not have generators. I want to like Dart but if puts me in the same boat as Javascript does on the server, then NO.
"For a Google-backed language to replace Rails"
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 [1], 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.
[1]: http://www.google.com/trends/explore#cat=0-5-31&q=dart%2C%20...
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 [1], 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.
[1]: http://www.google.com/trends/explore#cat=0-5-31&q=dart%2C%20...
Go's been out 4 years while Dart just hit 1.0 and requires a runtime as it's a bit less portable. Once Dart lands in Chrome, I can easily imagine it becoming the first choice of developers who prefer to develop code in their browser. A niche market now, but interesting to contemplate.
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.
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.
Oh, I see, that makes sense.
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.
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.
I've learned to not bet against the ingenuity of Google engineers, particularly those building web browsers and development tools. :) Given that they've added very basic support for editing to Developer Tools in Chrome already, once Dart lands in Chrome, I could see a push to make Chrome the editor-of-choice for Dart, if not web-based editors in general. And it's true, there's more to development than type-and-run interactive shells, but that sure makes web development easier, doesn't it? asm.js benefits Dart as well, since they can target the same approaches for their JS target code gen.
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?
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?
> Someone will probably be writing an OS kernel in Rust.
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 :/
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 :/
By that prediction, I did not just mean that someone wrote something in Rust that can boot and do kernel-y things... I mean that there will be a kernel project in progress that is not merely "intended to be serious competition someday", but something that you can seriously use for real, production projects as your computer's (or server's, or cell phone's, or something's) primary kernel/hypervisor/the thing actually running on the hardware. Indeed one of those projects may someday even become the kernel I am predicting, but I'd be very surprised if they are something anybody would seriously make their primary runtime today.
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.)
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.)
Absolutely, I agree. I was just trying to say that hopefully, there's some intrepid coder out there trying to do this, and that we have a few people who have started. We'll see where they are in a few years. :)
You seem down on both C and C++, but there will always be demand for languages that allow you to control memory.
Rust looks promising, but it's way too early to tell if it can really replace C/C++.
Rust looks promising, but it's way too early to tell if it can really replace C/C++.
I think what jerf means is that, being mostly used as a scripting and web language, it's easy to create legacy code in it. Remember ColdFusion? PHP 3?
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.
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.
That's pretty fascinating...I studied C in college and didn't hate it (in fact, I'd like to go back to C some day)...but my perception since has been that not much has changed because not much needs to change. I'd love to see a paper or article looking at innovations or change in practices in these older languages.
Not the OP, but I would expect to see still widely used:
* 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.
* 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.
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.
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.
In my experience (admittedly limited to only 3 specific instances), large orgs. have absolutely no problem with using Windows Server (often alongside Linux servers as well). B2B technology is remarkably Windows-centric even now, and I expect it will only become more so as time passes and Microsoft improves its server software and the .NET ecosystem, which is still pretty immature compared to the JVM.
"C# - C# is replacing Java as the OO language of choice for big enterprise systems."
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.
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.
Rumor goes that MS will likely make C# cross platform or open source entire .NET runtime, so that they can run Dynamics on Linux as well. In my opinion, if they did this, I would expect C# to get significant growth, and eclipsing Java.
C# is held back by windows
"The enterprise" (for the most part) isn't held back by Windows. That's just reality.
"The enterprise" (for the most part) isn't held back by Windows. That's just reality.
> "The enterprise" (for the most part) isn't held back by Windows.
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.
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.
Except Windows Server works fine.
Why group rust and go? Rust allows control over memory and go does not, which seems like a huge difference.
I'm not so sure about Lua. I'm under the impression that it's primarily used as a scripting language for games and things like that.
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.
JavaScript possesses a lot of the same benefits; it's a pretty simple language, boasts very impressive performance for a scripting language, and isn't very difficult to integrate with code written in other languages. As compared to Lua's downsides, it's a bit of a mixed bag. The syntax is immediately familiar to anyone whose used an Algol derivative, the language has some unpleasant quirks, but lots of developers are accustomed to them due to the language's substantial popularity.
I imagine Lua will still be a popular choice in 5 years, but I think it's going to lose some marketshare to JavaScript.
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.
JavaScript possesses a lot of the same benefits; it's a pretty simple language, boasts very impressive performance for a scripting language, and isn't very difficult to integrate with code written in other languages. As compared to Lua's downsides, it's a bit of a mixed bag. The syntax is immediately familiar to anyone whose used an Algol derivative, the language has some unpleasant quirks, but lots of developers are accustomed to them due to the language's substantial popularity.
I imagine Lua will still be a popular choice in 5 years, but I think it's going to lose some marketshare to JavaScript.
What makes you think Google won't be around. If they weren't, I'd put Mozilla on the chopping block as well.
[1]http://thenextweb.com/insider/2013/11/21/mozillas-reliance-g...
[1]http://thenextweb.com/insider/2013/11/21/mozillas-reliance-g...
"* 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."
Unfortunately I imagine that Google has enough money to be around at least 20-30 years.
Unfortunately I imagine that Google has enough money to be around at least 20-30 years.
Unfortunately? Yeah Google deserves to die, self driving cars, actual robots, Google glass, android, search, map reduce etc. Who needs this useless company that doesn't contribute anything to the world, right?
First off, popularity of a language shouldn't be as important as you seem to make it in starting a project. Finding the right tool for the job should be much much more important, new kid in town be damned.
Second off, number of package releases doesn't tell much about maturity of packages, developer involvement, or anything. Ruby's a mature language. It's quite feasible, and arguably desirable, for package releases to slow down in time. Styles have been developed, the urgency for new features to be rolled in Right Now is lessened, and the need for components that doesn't break on upgrades becomes more and more important.
Yes, the novelty is gone. That isn't a bad thing. You know Ruby's strengths and weaknesses, you know how to use it, you know how not to use it. Jumping to a new language just because of all the jibber-jabber is not a practical thing at all.
For all that, the more popular a language is the more packages are available and the easier it is to avoid reinventing the wheel and save time and effort.
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.
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.
> the more popular a language is the more packages are available
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.
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.
> Finding the right tool for the job should be much much more important
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.
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.
Not true. Ruby is great for a lot of stuff, but a very poor choice for e.g. scientific computing (scipy/numpy are a far better choice than the very immature sciruby), and plenty of other use cases where there are other "general purpose languages" that are far more suited to certain problems.
> Ruby is a general purpose programming language
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.
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.
I disagree.
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.
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.
Not at all, as the latest web framework benchmarks showed: http://www.techempower.com/benchmarks/#section=data-r8&hw=i7... (see rack-jruby, 86.3%)
It's really a question of how and what you run. And yes, the JVM is one of those options.
It's really a question of how and what you run. And yes, the JVM is one of those options.
Ruby the language is no more slow then Javascript the language is. Yes Javascript on IE8 engine is slow. On V8 it is not. Ruby on MRI is slow(though for most people, it's fast enough). Ruby on JVM is not.
> First off, popularity of a language shouldn't be as important as you seem to make it in starting a project.
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.
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.
Out of nearly-off-topic-curiosity, does this language have a website(page)? Was it new when you started your project? Have you been able to use libraries from other languages? Or is this really an island of 5 people? (Suddenly that sounds like Gilligan's island for devs)
I would prefer to keep the name out of the comments, just to prevent mud-slinging. That said, it is a proprietary language built for a niche data analysis market. It is basically a BASIC variant that probably came out around 95, and the application I now work with was started around that time. It was probably a great choice at the time, as its lack of extendibility was balanced by its performance and feature list in this particular space (GIS). Unfortunately, GIS has traditionally been a huge pain to develop for. The proprietary libraries really sink their teeth in on licensing and the open source modules are notoriously difficult to get up and running, especially in a server environment.
In response to this, I began building an open source javascript library that is nearing 1.0, and I am using it in new production work with great success. I chose javascript (node.js specifically) due mostly to performance with IO (huge in GIS) and its awesome ecosystem around npm. I am finding it much easier to build that one tricky library you need than to get the one tricky library for free and build everything else.
http://morganherlocker.com/post/turf
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.
In response to this, I began building an open source javascript library that is nearing 1.0, and I am using it in new production work with great success. I chose javascript (node.js specifically) due mostly to performance with IO (huge in GIS) and its awesome ecosystem around npm. I am finding it much easier to build that one tricky library you need than to get the one tricky library for free and build everything else.
http://morganherlocker.com/post/turf
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.
First off, popularity of a language shouldn't be as important as you seem to make it in starting a project
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.
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.
That's true if you're considering making something.
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.
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'm starting to think that the ROI on "learn Haskell and/or Clojure to expand your horizons" isn't there, even though I hate mainstream/modern OO so those languages would fit my mindset.
Maybe, maybe not. That kind of stuff is harder to quantify.
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.
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.
Developer discovers nodejs, drinks kool-aid, assumes other languages are dead or dying. News at 10.
So true, I was expecting to see Node code in this article even without reading it and can tell already that your comment is the whole tl;dr story of this post.
After Node will stop being popular and "hip" author will probably make a new post saying "Is Node Dying?".
After Node will stop being popular and "hip" author will probably make a new post saying "Is Node Dying?".
...and then checks it with numbers.
I didn't start using Ruby (or Rails) until this year. The language is nice and makes my top 3 language list.
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.
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.
> patently false 'convention over configuration' spiels
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.
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.
What is the criteria for being "the new PHP"? Do you mean that it will be used for the same kinds of projects as PHP is currently used for, or by the same types of developers or ...?
Ugh...must not take Lord's name in vain. 14 points in almost as many minutes? Is it so easy to get to the top of HackerNews on a holiday with such a loaded question? I can't imagine how many points the OP would've gotten if the title was "Is Ruby Dying Faster than MongoDB?"
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.
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.
Cannot agree more with you on that last comment. I personally think - and hope, as a full-time Ruby dev at this moment - that Ruby will "recide" (big quotes here) to a more "humble" spot as a glue language; i.e. Perl's spot 10-15 years ago.
Not a bad spot to be in if I may say so.
Not a bad spot to be in if I may say so.
Is it that day of the week again?
I would like to also point out the title of the post is misleading, as the findings are exactly the opposite.
I would like to also point out the title of the post is misleading, as the findings are exactly the opposite.
Citing this is such a knackered HN cliché it should mean an instant hell-banning.
Complaining about a "knackered HN cliché" is itself a knackered HN cliché. Recurse.
Shouldn't submitting things that fit Betteridge's Law should get you banned instead? Why ban the symptoms?
My comment was tongue in cheek, but there is no way one would realise that just by reading it. I don't really think people should be hell-banned for it, being down-voted into oblivion would suffice :)
TIOBE index for December 2013 says otherwise:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index....
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.
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.
> 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 [1], 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 [2] 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.
[1] http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td...
[2] http://groovy.329449.n5.nabble.com/Groovy-3-tt5710334.html
Groovy's roadmap just added version 2.3, featuring "_Traits_", which were actually originally announced for version 2.2 [1], 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 [2] 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.
[1] http://groovy.329449.n5.nabble.com/Adding-Trait-to-Groovy-td...
[2] http://groovy.329449.n5.nabble.com/Groovy-3-tt5710334.html
Ruby is still holding its own in he HN hiring trends too[1]
[1] http://www.ryan-williams.net/hacker-news-hiring-trends/2013/...
[1] http://www.ryan-williams.net/hacker-news-hiring-trends/2013/...
TIOBE results for Ruby won't be the same just quite yet, because December 25 is the traditional Ruby release date. Ruby will get a lot of press over the next week that's still in December, but wouldn't be counted yet.
I used to look at the TIOBE index all the time, until I saw Visual Basic .NET jump a bunch of spots this year. I then started to question either TIOBE index or the people that are using Visual Basic.NET
Not sure what to say about TIOBE. It bases its results on search engine trends.
They can't really tell the difference between Ruby(The stone) and Ruby(The language). Or Python(The snake) and Python(The language).
They can't really tell the difference between Ruby(The stone) and Ruby(The language). Or Python(The snake) and Python(The language).
NodeJS, been there done that. Even with generators it makes doing task synchronously a royal pain(have you ever tried to write sql update code with transactions?). Until something comes a long to replace Ruby(https://github.com/mirah/mirah looks promising), I'll still use it. Ruby is a great scripting language, and it has one of the best(if not the best), web frameworks out there.
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 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).
Mirah has almost zero usage, and it seems very little development is going on there. I'm on the Mirah google group and there have been 5 posts since October.
I love the idea, but it seems few are interested....
I love the idea, but it seems few are interested....
Exactly. That proves my point. There are no Ruby like languages ready to replace Ruby right now.
Ruby is like Disco. It was fun for a while, but now it is old news.
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.
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.
A better title would have be, "Is Ruby Dying? Getting The Data." As others have pointed out, the data suggests no, it is not.
But then it wouldnt be linkbait!
I was taught that if the title of an article or story asks a question, the answer is almost always, "No."
Betteridge's Law Applies.
With javascript:
http://www.google.com/trends/explore#q=python%20programming%...
I don't think it's comparable to compare the 1-word "nodejs" with the 2-word "xxx programming" phrases.
sans "programming" http://www.google.com/trends/explore#q=python%2C%20ruby%2C%2...
They are roughly at the same level of google trend popularity if you use just language names (w/o 'programming'):
http://www.google.com/trends/explore#q=python,ruby&cmpt=q
EDIT: This one is maybe more accurate (w/ 'programming' as selected category) and it shows that interest is roughly the same on average: http://www.google.com/trends/explore#cat=0-5-31&q=python,+ru...
http://www.google.com/trends/explore#q=python,ruby&cmpt=q
EDIT: This one is maybe more accurate (w/ 'programming' as selected category) and it shows that interest is roughly the same on average: http://www.google.com/trends/explore#cat=0-5-31&q=python,+ru...
Better search terms: http://www.google.com/trends/explore#q=%2Fm%2F06ff5%2C%20%2F...
I have been working with Ruby and RoR for a few years now after using C# and Java. I now can put together web apps or APIs in hours vs days and integrate it with about anything out there from other APIs, using gems wrapping them or other gems for integration like redis, rabbitmq etc you name it. I have never ran into issues of incompatible gems I could not fix myself in a short period of time. It's incredible productive and reasonable fast. I am dealing with data reads/writes in the ten thousands of records per second and when something smells like bottleneck you still can throw in a native extension or use jruby and call java libs. If you are building all you do with boilerplate activerecord or other ORMS you just don't use it right. Flexibly is key. I think every challenge has it's best tools. I tried grails, play, spring mvc and other frameworks but promise that I can beat every of these frameworks in terms of development speed. Ruby is far from being dead and has a huge community. Having that said its always good to also stay up to date with other tools. For many deploying rails apps is a pain so why not throwing in warbler and deploy a war file to an app server...seconds later, boom, online and scalable. I could go on for hours:) I am a fan and so are our shareholders.
> What do you guys think? Is Ruby dying? Did you once use Ruby and have now started to use something else?
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.
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.
after looking at the node code in the article, no.
Ruby is maturing, not dying. It has lost much of its fadish hype.
Ruby isn't dead. It's stabilizing now that all of the language hipsters have moved onto Go/Node.js/Scala/Clojure to recreate a bunch of mini Web libraries to try and make names for themselves in the new languages.
Ruby's best days are still far away.
Ruby's best days are still far away.
Ruby is only dying in the sense that C is dead. It's not that exciting, but instead is widely used, including by companies.
Additionally, I doubt gem releases correlate with language 'vitality'. Fewer releases may simply indicate library stability.
Additionally, I doubt gem releases correlate with language 'vitality'. Fewer releases may simply indicate library stability.
Too true, I'm writing more C lately than ruby. Then again I'm not a rails fan and I need to interface with ioctls more than oauth or whatever. So C fits much better in my domain space.
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.
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.
That's a fifteen year graph, and does appear to depict a decline at the end. I'd like to see this data rescaled to just the last six months (unfortunately his data files are 404ing now).
If you want to find out if TV sales are declining, you don't compare against the 1950s.
If you want to find out if TV sales are declining, you don't compare against the 1950s.
It is surely dying among those folks who only build one page apps and post them to blogs...
The author must be pretty wet behind the ears if they think a blog audience will want to read huge blocks of mundane javascript code with console logging and error handling.
If there is one person working on the next version of ruby it is not dead.
jruby and rubinius close the performance gaps. (This is an arguement for only knowing one language.)
jruby and rubinius close the performance gaps. (This is an arguement for only knowing one language.)
[deleted]
my question : is ruby trying to get on pair with python regarding machine learning ?
not even close. even lua is way ahead of ruby in machine learning !!!
As always, the answer to posts with a question as the title, is no.
Pure Hacker News bait.
graph only shows that all smart coders switched to ruby and it is steady updating
also most gems in all areas are good enough already
also most gems in all areas are good enough already
Netcraft needs to confirm this, first.
Probably not.
[deleted]
I know Ruby on Rails isn't!
No, but BSD is.
Wait? What????
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!