Slashdot Mirror
Is Ruby Dying?
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."
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. 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.
Computer simulation made easy -- LibGeoDecomp
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.
The cool kids are using Go for their server apps and infrastructure projects.
While their parents are taking real jobs and paying the bills!
Lisias@Earth.SolarSystem.OrionArm.MilkyWay.Local.Virgo.Universe.org
Chef and Puppet are huge in DevOps. It seems Ruby has found its niche.
Now people can spend much more time actually writing applications than writing supporting infrastructure.
"To those who are overly cautious, everything is impossible. "
Node.js invents threading/processes and is webscale.
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.
http://saveie6.com/
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.
No. Next question, is Slashdot dying?
Slashdot will be dead as soon as the new "design" comes out.
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.
You're the guy who told me to get off his lawn when I first joined, aren't you?
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.
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 Python have found other niches where they thrive. Can the same really be said of Ruby?
Chuuch. Preach. Tabernacle.
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.
Futurist Traditionalism
Dear Ruby: Please leave Chef behind and go and die in some dark corner. Take rails with you. Thanks.
For quick and dirty scripts, you can just define your methods and variables and not deal with classes. They're added to the main object, much like javascript globals and functions are added to the window object.
Do you even lift?
These aren't the 'roids you're looking for.
No you do not need to place a function in a class.
irb :001 > def add5(x)
:002?> x + 5;
:003 > end
:004 > add5(10)
:005 > add5(12)
2.0.0-p353
2.0.0-p353
2.0.0-p353
=> nil
2.0.0-p353
=> 15
2.0.0-p353
=> 17
These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
Hmmm. 46 here. And apparently still too fast for Slashdot who tells me to "Slow down, cowboy!"
:snicker:
I'm 53 - but was relatively late to the party (and I've tended to have younger coworkers, one of whom introduced me to /. a decade or so ago).
I suspect any age to UID correlation has a pretty large sigma. I wouldn't be surprised if the four and five digit UIDs demonstrate a big cluster of people who are now between 30 and 40, though.
#DeleteChrome
Bad language or not, it is already used heavily on the client-side. Using it server-side allows you to make use of the same objects without having to maintain things like validation logic in two languages. It also means that if you are using Karma or something similar for testing that you only need one testing framework. Otherwise you'd need two testing frameworks running. Switching gears from one language to the next isn't hard but going from strongly typed to dynamic often results in developers trying to strongly type their javascript or writing it in such a way that it becomes too rigid. Tests should be governing everything anyways, especially if it is TDD.
My company is using C# on the back-end and javascript on the front. I write php+javascript at home though (and have experienced a life-time of derision from "professional" developers for it). I still write C/C++ for linux and embedded projects. Too many developers have decided their language is the best and everything else is horrible. When really, every language is covered in warts. Every language has (had) growing pains. Have you ever wondered why if your language is the best it is rarely used in all situations? That's because it's not the best tool for every job.
Your kind is nothing new. Anyone who has a passion for programming runs into people with your attitude and just shrugs. It is almost like dealing with a form of bigotry.
http://soylentnews.org/~tibman
You're wrong. While it's true that "everything is an object" in Ruby, a lot of it is implicit. E.g. you can define "global" functions - they just end up as methods of Object. And because Object is a base class of any other class, you can call those methods directly in any piece of code. So it's OO, but you can completely ignore it if you want.
"Everything is an object" in Python, too, by the way. Global functions there become methods on the module object for the module in which they are declared.
All in all, this just means that the type system is simplified (no separation into primitives and objects etc).