Slashdot Mirror
Is Ruby's Decline In Popularity Permanent? (computerworld.com.au)
An anonymous reader quotes Computerworld:
Ruby has had a reputation as a user-friendly language for building web applications. But its slippage in this month's RedMonk Programming Language Rankings has raised questions about where exactly the language stands among developers these days. The twice-yearly RedMonk index ranked Ruby at eighth, the lowest position ever for the language. "Swift and now Kotlin are the obvious choices for native mobile development. Go, Rust, and others are clearer modern choices for infrastructure," said RedMonk analyst Stephen O'Grady. "The web, meanwhile, where Ruby really made its mark with Rails, is now an aggressively competitive and crowded field." Although O'Grady noted that Ruby remains "tremendously popular," participants on sites such as Hacker News and Quora have increasingly questioned whether Ruby is dying. In the Redmonk rankings, Ruby peaked at fourth place in 2013, reinforcing the perception it is in decline, if a slow one.
What is Ruby?
Meanwhile, we grown-ups use Perl and C and laugh at the demise of this week's hipster language.
Now get off my lawn.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Oh yeah and C++ has been around for 38 years. It ain't going anywhere, especially with Moore's Law ending.
It's pretty clear that Python's going to come out on top of the GenY/Millenial coding club. Ruby got a quick lead making Web 2.0 development easy but Python hit critical mass just by the number of available packages. Numpy, Matplotlib, etc. "How to ___ with Python" nearly always turns up a result.
And peers: No, just like COBOL and FORTRAN, C and your current $favorite_language isn't ever going to go away. I still do a lot of C, Matlab and Simulink at work. But when I have the opportunity Python is just faster due to the shear number of packages that already exist.
Yes.
The web fad moved on. They're never coming back. And good riddance.
Ruby will continue to grow in popularity for other types of uses.
Puppet just hangs. It's not Windows-specific; it's a feature of this nightmarish system. I've seen cases of million+ queued jobs slowly murdering the masters. Maybe it works if one has 3 servers and 12 lines of config but in a real environment it's just a terrible system.
Take puppet to the backyard and shoot it in the head. Then bring in Ansible. No flaky agent, no constant chat on the network, no mysterious ordering of tasks, no need to find countless plugins written by random people to do the most simple of things. I've seen Ansible work smoothly on 2,500+ servers with fairly complex variations in configs and dynamic inventories.
I've never seen anything good written in ruby and puppet is just par for the course.
lucm, indeed.
As far as interpreted languages are concerned, Ruby is by far my favorite. I can code in that language far faster than any other, despite having decades more with the likes of C and C++. It’s nice for quick-and-dirty prototypes and things that don’t require a lot of processing power. But for serious tasks, it’s just too damn slow. I have tried, for instance, to write parsers in Ruby because its string and array manipulation are really convenient, but for most data sources, the Ruby programs just can’t keep up. And I’m no slouch at playing “golf” with intricate Ruby expressions. What’s worse is that with the global interpreter lock, I can’t get more throughput from threading.
I’m not a huge fan of Python in terms of syntax, but although general Python code is of comparable things, Python has some tools that make it invaluable. I’m thinking specifically of sympy and numpy. Simpy is an amazing symbolic algebra library. I can’t tell you how nice it is in machine learning to be able to have it automatically compute partial derivatives of arbitrarily complex expressions. And when you can organize your data into vectors and matrices, numpy can use GPUs to get incredible throughput. This is the only reason I bothered to learn Python, and it’s one reason Python is eating Ruby’s lunch.
Rails may be taking a back seat, but Chef is very much in use, and will be for some time to come.
~ People that think they are better than anyone else for any reason are the cause of all the strife in the world.
Ruby is fantastic for writing a-lot of code quickly. But it has terrible performance, and is has terrible maintainability characteristics (I recall doing global file system searches to find the file that defines something that my code requires, which is brought in by another require, and then another).
Performance sometimes matters. If one's app requires 20 VMs in Ruby, but only 2 VMs in Go or C++, then the cost difference can be substantial.
Also, Ruby - while 20 years old - is surprisingly immature. E.g., a few years back, I wrote a multi-threaded program in Ruby. It didn't work. After days of scratching my head, I discovered that while Ruby used native threads, it had a global interpreter lock, forcing the native threads to take turns. Maybe they have fixed this by now. My program needed true concurrency, so I had to re-write it using processes. Gosh - Java got threads working after the first two years.
Firms that really know how to maintain large codebases have also discovered that type-safe languages are very effective for maintainability. Check out this post: https://medium.freecodecamp.or... . I myself have experienced this: I once translated a fairly good sized codebase from Ruby to Java, and in the process discovered a large number of potential bugs - thanks to Java's type safety. I have found that when I refactor Java code, I introduce zero new bugs, but when changing Ruby code, the only thing that prevents new bugs is a large suite of unit tests. Thus, writing in Ruby _requires_ that one write comprehensive unit tests. I personally don't use TDD - I use ATDD, so my focus is on acceptance tests, not unit tests. Ruby _forces_ me to write unit tests. I don't want to be forced to work a certain way.
I am not bashing Ruby - I think it is great for some things - but people (like those at Google) have come to understand its shortcomings.
I have never touched Javascript and I know nothing about the 'promise' construct, but people don't use callbacks, upcalls, futures, promises, or whatever they are called for the fun of it. They do it because the sequential execution model is not good enough. They have to deal with unscheduled events, including user clicks; they have to communicate with other systems that will reply at an unpredictable moment in the future (if at all); they have to move lengthy computations out of the main thread to avoid sluggish response to the user. Or they just have keep multiple cores busy and coordinate the work on these multiple cores.
Thus, i'm pretty sure JS does not 'really, really wants to use callbacks to sequence things', it wants to offer a mechanism to break out of the rigid sequencing of imperative execution. If and only if necessary.
Problem is that many many Javascript libraries now use callbacks as a normal method of operation, often when it's not necessary. The result is now you get the "callback of death" with many nested layers of callbacks. It is ugly but worse, hard to read. Here is an example and some solutions.
"First they came for the slanderers and i said nothing."
Whatever language and framework you or your team is most versed in.
You can do this in PHP if that's what your programmers know but when you set forth programming language requirements based on mostly managerial gibberish, you've failed at design.
Whether your applications is going to end up with a REST or SOAP interface with an RDBMS or NoSQL backend is largely unimportant to the customer, as long as it works, is done in time and is easy to maintain.
For a new application, since you specified you 'require' REST as an API, I wouldn't even go the layer of ORM + RDBMS, most of the time an Object Oriented DB may be sufficient here since you don't require any state and most inquiries will be (or should be) simple. So since you've got REST + OODBMS and you need a service layer - at this point, I'd be looking more at Zend or NodeJS because those are the broadest understood and fit better with your prerequisite of a stateless object-oriented API.
Custom electronics and digital signage for your business: www.evcircuits.com
When the rise and fall of the Ruby empire is written, Chef will probably have a part in both stages. Ruby is more a victim there, but some of my most frustrating encounters with Ruby have involved Chef. Sticking to Ruby earned Chef favour from developers but Puppet's custom DSL choice was the right one. Using Ruby forces hard dependencies where everything ends up being dependent on 'windows' and 'yum' and 'apt'.
A major problem with the first era of config management / DevOps was too much code that does too little. Instead of telling Chef via an abstraction to enable the apache service, you have to write:
And this is one of the better written actively maintained cookbooks.
Then there is the annoyingly common convention where every time there is a new release of the underlying package, you have to update a hash in the Chef code and release a new version of the Chef cookbook, which of course is delayed - looking at you Elasticsearch.
It runs 'yum install elasticsearch' which installs a signed package from the repository. But the first law of config management is 'support everything and let the lowest common denominator dictate design'. So supporting whichever crappy OS / release that does not have native packages always takes priority over writing something that just works and will continue to just work.
e.g. The Chef yum provider can't handle obsolete package versions. If you tell Chef to install somepackage-x.y.1, and that version has been obsoleted by somepackage-x.y.2, somepackage-x.y.2 gets installed while Chef thinks it installed somepackage-x.y.1. The next time you run Chef with exactly the same config, it will fail because of the implicit downgrade.
Which brings us to the Third law of config management: Idempotence in config management is like world peace for the U.N. - promising an idealized unachievable goal confers nobility and thus failing at it all the time is ok.
Ruby isn't the culprit here but it is the enabler. Manual dependency management means no one configures versioned cookbook dependencies. So your infrastructure is code defined, but what that code is is a spur of the moment thing as Chef fetches the freshest stuff off supermarket.chef.io. Bringing us to the second law 'it mostly works' is good enough.
In the world of clustered distributed multi-node services, the much praised Kitchen test framework can't test multi node deployments. Have a two-node Elasticsearch cluster - forget writing tests, and add a bunch of timeout hacks to handle asynchronous builds. Let's have a long existential discussion over whether multi-node testing is really needed and continue to write tests for whether "package 'ap