Is Ruby Dying?

[John Moses]

http://jmoses.co/2013/12/21/is-ruby-dying.html

I have been working with nodejs alot lately and have been discussing with coworkers if nodejs 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.

I think 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.

 

[SD!]

http://jmoses.co/2013/12/21/is-ruby-dying.html

I have been working with nodejs alot lately and have been discussing
with coworkers if nodejs 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.

I think 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.

Ruby as a language is the most beautiful thing ever devised since 6502
assembly! And no web framework of the month is going to change
this. But - no matter what some people are going to say about this -
IMHO one of the biggest obstacles for taking Ruby into more use is
actually the gems system. Gems should be repackaged as regular packages
(e. g. for Debian/Ubuntu) and available from within te system's regular
packaging/installation mechanisms. There should be NO special
treatments necessary. No rvms, no gems, no nothing else than system's
native packages that any and every admin could just simply install the
same way as virtually every other package.

As long as there will be arguments against this (read: excuses) only
the fans of Ruby will always want to deal with the non-system-standard
installation/distribution mechanisms. I am a fan of Ruby but I can't
make it easy for Ruby indifferent admins to set whole Ruby ecosystem up
and running (reliably).

 

[Steveskok]

Well, we have to deal with the reality. RoR is not a young structure anymore, and the competitors is rather high. Every now and then, new innovations show up, and designers contrast, evaluate, and provide their viewpoints regarding them.

The objection concentrates on sluggish efficiency, scalability problems, and that it's not "fresh" technology. RoR might be a bit slower compared to C++ or Golang, however it's visible just with a big job with huge traffic. People (particularly junior designers) state Ruby on Rails is not scalable sufficient. However we cannot criticize the 100% structure for that. Scalability problems can occur due to any type of data source disruption. Obviously, we can state that Ruby on Rails is not a "fresh" innovation, however, is it a drawback? Fully grown structures are well-tested, steady, and dependable.

The essential point, RoR structure is a device in the hands of designers. It can be utilized properly or improperly. Programs (in every innovation) needs progressed abilities. That is why it's necessary to select the appropriate group with Senior citizens aboard for the job. Indeed, choosing the appropriate people for the application advancement job is important.