Looking for a job right now, not limited to any specific language, and I see Ruby mentioned plenty of times. Based on that, it seems the reports of Ruby's decline are not as bad as sometimes claimed.

If you look at PostgreSQL then a lot of dev work comes from EnterpriseDB and a handful of companies too.

The thing with Rails is that it doesn't scale terrible well to "Twitter scale" (if I'm not mistaken Twitter has dropped all usage of Rails) so there aren't that many well-known companies running it, but the overwhelming majority of companies are not "Twitter scale" and it's not really an issue for them. There's a long list of smaller outfits that are not in the "top 50" using Rails quite happily.

People focus too much on "What is {Twitter,Facebook,Google,Amazon,Netflix,...} doing?" Who cares? You're never going to have the same problems they have. And whatever they are doing is not necessarily representative for the entire industry.

> The thing with Rails is that it doesn't scale terrible well to "Twitter scale"

It's true that Twitter switch to JVM langs, but it's not true that Ruby doesn't scale (or couldn't have to Twitter's level if they'd kept it). Twitter was early days for Ruby and things have improved a lot, but the only scaling challenge with Ruby is the cost of app instances. I use Elixir/Phoenix now and run 1/4 of the app instances I used to and with much less memory required per instance. (in one app it's 1/10 the ruby instances!) It's traditionally opex cost that hurt Ruby scalability, not technical, and very few companies will ever see the level of success where the cost of servers gets prohibitively high (compared to dev dev cost).

Isn't "it's comparatively slow" what people usually mean with "doesn't scale"? You can scale anything with enough hardware, but as you mentioned at some point is just becomes very expensive.

Twitters architecture at the time was a textbook example of how not to build a large scale many-to-many social network. Maybe switching would've been worth it for them anyway, but the big thing they needed was fixing architectural choices they never should've made to start with.

> Isn't "it's comparatively slow" what people usually mean with "doesn't scale"?

If that's the case, then they are misguided.

> You can scale anything with enough hardware

No, some architectures or implementations can give you diminishing returns or a hard cap. Not everything can scale horizontally ad infinitum.

> Looking for a job right now, not limited to any specific language, and I see Ruby mentioned plenty of times.

This furthers the point. By stating a lot of companies are looking for Ruby (something that doesn't match my experience when looking) is not a testament that it is hot and in-demand, it is a testament that those roles are not being filled. Senior devs don't make senior dev money doing junior dev work. My assertion is that the majority of Rails is CRUD development that only gets difficult when you step off the golden path- ergo, those positions go unfilled and outnumber their statistical representation in what would be called 'production Rails applications'

What does "hot and in-demand" even mean, exactly? All I'm saying is that based on my (admittedly limited and vague) dataset there seem to be plenty of companies happily running on Ruby (some with Rails, some without) and that "FAANG-type companies we all heard of aren't using it that much any more" doesn't actually mean all that much.

I'm not really sure what your point about senior/junior devs or "roles are not being filled" is.

(aside: please don't delete your post and post exactly the same identical post again to clear the downvotes on it).

twitter was never a good fit for rails anyway. twitter is basically a human pubsub at scale. Rail's bread and butter are simple crud based apps with nonlinear use patterns.

> - rails is mostly needed for prototyping and crud apps

> - this work is typically done by juniors

> - rails devs are at this point largely seniors, not juniors

> - rails devs pay the bills with other tech or by maintaining legacy rails apps.

- and those prototyping apps have very often gone through multiple teams, some or all of them probably outsourced. Potentially true of any codebase, but it's true of an exceptionally high proportion of Rails codebases.

I'm at the point where I'd want a stupid premium to come in on an existing Rails codebase, and I'd want a day or two with it before saying "yes" even at that. They're great if they've been maintained by professional, expert teams their whole life, but god-awful messes remarkably resistant to analysis, otherwise.

I like Ruby a lot but most of the jobs are in Rails, and after initial infatuation followed by repeated exposure over 15ish years, I've come around to pretty much hating Rails. Too much implicit magic, too much memorization, too opaque to tools that might help overcome those first two problems.

> Too much implicit magic, too much memorization, too opaque to tools that might help overcome those first two problems.

If you are a senior level Rails developer none of this is true except maybe memorization and that seems to be a pre-requisite for any senior engineer in any language. It's trivial to debug rails applications with debugger and reading the underlying source code. Everything you need to solve problems is a binding.pry or `bundle open` away.

If you're having to poke around in running code to find out WTF some symbol even is and where it comes from, and that's not a very uncommon thing to have to do, that's unacceptable IMO.

> that seems to be a pre-requisite for any senior engineer in any language

In many languages and language-ecosystems, there's little point to memorizing e.g. method names and signatures that you're not using so often that memorization happens naturally, because your tools can remind you when you, fairly seamlessly, when you need to know. A lot less memorization goes a lot farther in those worlds, than it does in Rails, and the pain of encountering something one is not familiar with is near-zero. Coming back to them after a year or two—or five—away's not a big deal. The brain-space required for Rails is unusually large, and the rate of rot in Rails skill is high. Ramp-up time in an unfamiliar Rails codebase is rough, and requires assistance from those already "read in" to avoid a bunch of wasted time tracking down which gem provides such-and-such dynamically-named object or method or what-have-you. "Which library is this even from?" is not a question that ever reaches the level of conscious thought, in many other languages & frameworks.

Getting up-to-speed on an unfamiliar Rails codebase is full of little side-quests that simply aren't needed elsewhere, and you have to hold a lot more in your head to remain productive in it, than other systems require. This is obviously not impossible, but... oof, why?

All that written out... there's a chance I'd still pick it for a new, solo project, depending on the task. It's fine as long as you are very-familiar with the entire codebase, and some of its gems are major time-savers. I get why companies, and especially move-fast prototyping startups, end up with it, I'm just very done onboarding to existing Rails codebases, personally, without some serious pain & suffering compensation.

> If you're having to poke around in running code to find out WTF some symbol even is and where it comes from

I see this people complain about this but I don't understand why. First of all I've seen highly competent engineers complain about methods in Rails that exist from basic inheritance in Ruby. A concept that they probably learned when they were 10 years old. This is how object-oriented code is written. Pretty much every game is written the same way. Yes the dynamic methods that are generated can be annoying, but not what I see people complain about.

Second, they're trying to code a language like Ruby in a text editor and complain. If you tried to write Java or Scala in a text editor you would also have a bad time. So, yea I don't get it to be honest.

Are you suggesting php and JS are stealing from what would've otherwise been ruby projects? I've been a ruby dev for a decade and I've never heard of a ruby shop migrating to using php for new work and maybe one or two moving to JS for new work. It's golang and elixir that are taking the place of ruby for new work in my experience. I suspect some python too, but I haven't seen that.

I think they're suggesting that neo-PHP and JS adopted the best parts and patterns of Rails (eg. Laravel).

I've spent the majority of my time on Ruby since 2005, and only about 2 of those years have involved any Rails at all. There are plenty of opportunities to use Ruby in other contexts, but it's often less flashy. Most of my Ruby use have been e.g. in devops behind the scenes where the job description might not list a language.

I mentally put Ruby / Rails and Python with Flask / Django (and also “neo” PHP) in the same category vs all of the 70 million JS frameworks. When you talk about alternatives, what are the major ones you have in mind?

Admittedly I haven't written any ruby code in a very long time, but you only briefly touched on the reason we ran away from it after giving it a serious try:

> rails devs pay the bills with other tech or by maintaining legacy rails apps

That "maintaining legacy rails apps" job just doesn't exist with our PHP apps. Once properly tested and deployed PHP will generally work perfectly and smoothly for years with zero maintenance unless someone finds a bug that was missed in testing. You can pretty much setup a cron job to apply security patches and that's it. Maintenance done.

The only downtime I can recall was when our datacenter installed buggy firmware on their storage array and brought down every virtual machine we had with them... which was a pretty rare and unusual event (by the time they fixed it, we had already moved everything to another datacenter... and it seems we weren't alone because they went bankrupt).

With ruby that wasn't our experience at all. We found our production code would regularly just stop working and resources had to be pulled off other tasks with zero notice to figure out why/fix the issue. It was a productivity nightmare. Maybe that's improved now, but from reading the Shopify and GitHub blog posts they both seem to be taking on mammoth amounts of work to ensure their systems are reliable.

At the companies I work for (more than one) we expect anyone qualified to do work like that to be dedicating all of their time to other things. All of the apps we built in ruby were rewritten from scratch in PHP and we haven't had any regrets.

I've never really liked PHP and I actively hate JavaScript, but I've come to accept those two languages are just more practical than anything else. I'm definitely keeping an eye out for that to change though - Swift is look promising for example.

The story you're telling sounds like a you guys problem, not a Ruby or Rails problem. I've been building and running Rails apps since 2007 and have not experienced what you've described.

My current app runs on AWS ECS. Upgrades are largely just updating my Dockerfile or merging a pull request from Dependabot. We have pagerduty and it only goes off when a 3rd party API is down, usually resolving itself.

Sounds like you know how to build PHP apps and didn't know how to build Ruby apps. That's fine, and a valid reason for you to pick what worked for you. I've had plenty of Ruby apps just run for years without additional work.

while rails is great, its comparative advantage has wanned a lot over the verses since it first came out. Its biggest competitors were spring and zend framework (also hunchentoot if you're THAT kind of guy). compared to those, ruby was a breath of fresh air.

Nowadays it has to compete with nodejs, phoenix framework, django and laravel. all of which are within 80% of developer productivity while being vastly more performant. I use phoenix framework myself and while I wish there were more packages available, developer productivity is good enough and we can get away with far less machines to do the job.