After 25 years it seems Ruby is in gradual decline these days? You will find one ruby related post at HN after reading 500 of Javascript and/or Python posts here for example.
I think Rails is the obvious choice for backend apis these days. It's robust, takes care of most of the hard stuff, saves you time and mistakes. Use whatever you want for frontend (React for me) in tandem with it. Many of the job postings I've seen have listed Rails + React.
It used to get accused of scaling poorly, but tell that to Github, Gitlab, and other large-scale sites with millions of users. It's true that bad Ruby is slower than bad Java, but the solution is to write cleaner code.
I know this was all about Rails. I use Ruby for scripting work as well, and it's enjoyable to use.
I've worked on one such large-scale enterprise-level web app, and it really does scale poorly in some areas, specifically database management. ActiveRecord tends to get extremely expensive when db's take on large amounts of records and complex relationships start forming between those large tables. You need VERY good software engineering practices and understanding of which choices will utterly kill you down the line in terms of performance when using this ORM, and it's hard to see those consequences at the outset due to the fact that Rails code is so easy to pick up and understand.
```
User.joins("left join ponies on ponies.user_id IN (select id from foobars where user_id=users.id").group("so_funny").count
or I could have a policy to avoid joins at all cost and reject any commit that uses a join and get fun things like:
```
users = User.all # all fucking hell
JSON.parse(HTTP.get("http://your-things.json"))['results'].select {|r|
users.detect {|u| u.id == r['user_id'] } # for realz??
}
[edit]: cause formatting
This is compounded by the fact that ActiveRecord obfuscates much of the sql code you posted above (not always, but in many cases). When a user new to Rails goes in and sees "Oh, all I have to do to set up foreign key relations is to just say this model belongs to this other one? NICE!", it isn't immediately clear what the implications of whats happening under the hood to accommodate that are, and all of the ways which this can quickly be misused to cause a huge performance bottleneck. That syntactic sugar smooths over some of the pitfalls of efficiently interacting with a relational DB.
It's important to note that these things do not make ActiveRecord a bad ORM in and of itself, as many users will not build projects large enough to have to worry about such bottlenecks, but it CAN and DOES cause problems when projects get larger and have to start taking on overhead from the resources allocated for all those records. That is what people are complaining about when they mention Rails doesn't scale well (or at least one of the reasons).
Yes, there are tools in ActiveRecord that can help mitigate some of the performance issues, but as I noted above, it's extremely easy to overlook such tools until you are too far down stream to really do much about it. The symptoms of not using such features may not show up until much later when the number of records swells, and some code someone wrote 2 years ago starts slowing down the whole shebang simply because they used a select rather than a pluck. This is ESPECIALLY true in large corporate web app environments where the number of records is large and the number of people with their fingers in the code base is equally sizable. And good luck convincing management to go back and fix old ORM tech debt until the whole thing starts falling apart at the seams.
Hell, pluck didn't even exist until 2012 with the release of 3.2.1.
What's a lot harder to deal with is AR callback hell, which can be very slow if you have enough nested callbacks, and can be really hard to fix without breaking everything. Using many AR callbacks is just a bad idea for a big app!
For a programming-community this is very very bad. Programming is not only about the language itself, but also the libs, frameworks, tools, and that's what most enytrys about python or javascript are. When the community of Ruby on a nerd-meltingpot already is so low that they hardly share any content, then how much less recognition will they receive in more mundane and conservative communities?
Now less recognition will mean less new users, less new libs/frameworks/tools&support. Over time the existing users will move away or just die, which means the decline has started.
I think the focus on Python these days has more to do with the fact that it's often the language people learn first these days, and the fact that it has effectively supplanted Perl as the swiss army chainsaw of scripting languages. I think Javascript is popular due to the fact that it is essentially the native scripting/programming language of the modern web (or at least it will be until WebAssembly really catches on), and the ridiculous preponderance of decent frameworks that are out there now for that language.
On the other side of the world, Ruby has many adherents in the embedded development world. A large number of the Japanese talks are about mruby and that has motivated many of the last few years of the languages' improvements.