5 ms·

I agree with the other poster who says it's mature, not in decline (so maybe that's boring to the crowd that likes to always hop to the latest tech). Basically

I agree with the other poster who says it's mature, not in decline (so maybe that's boring to the crowd that likes to always hop to the latest tech). Basically most of the kinks have been fixed and desired features have been added, and now it's about gradual improvements and adding new functionality as it comes. Students also commonly learn Python and Javascript in college and are probably more active on social media like HN. 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.

Rooster61 8y ago
> It used to get accused of scaling poorly, but tell that to Github, Gitlab, and other large-scale sites with millions of users. 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.
- taf2 8y ago
  Isn't this true of any language? I mean the language isn't what decides how you connect or build your sql queries? In rails I could choose to write a pretty scary join ``` 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
  - Rooster61 8y ago
    You are right, but aren't really attacking the point I was making. Even with totally optimized sql, one language's ORM will be inherently slower than another due to the intrisics of how the records being operated on are represented in that particular language. In Rails's case, EVERY single record pulled out of a database gets its own object. There is overhead to being able to represent table members from a relational database in a language with all of the lovely convenience methods tacked on to the resulting object (things such as treating ranges of records pulled like a hash, for instance. 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).
    - taf2 8y ago
      That is why we have pluck
      - throwaway427 8y ago
        Exactly. Use pluck, use exists, use count, use find_in_batches. Be thoughtful and have a culture of code reviews. Simple enough.
      - Rooster61 8y ago
        > 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 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.
PurpleRamen 8y ago
Mature is a humble way to describe stagnancy. Something/one has stopped growing and will likely never become better than it is now. This is on shortterm no decline, but will longterm evolve into it. 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.

Rooster61 8y ago

> It used to get accused of scaling poorly, but tell that to Github, Gitlab, and other large-scale sites with millions of users. 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.

taf2 8y ago
Isn't this true of any language? I mean the language isn't what decides how you connect or build your sql queries? In rails I could choose to write a pretty scary join ``` 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
- Rooster61 8y ago
  You are right, but aren't really attacking the point I was making. Even with totally optimized sql, one language's ORM will be inherently slower than another due to the intrisics of how the records being operated on are represented in that particular language. In Rails's case, EVERY single record pulled out of a database gets its own object. There is overhead to being able to represent table members from a relational database in a language with all of the lovely convenience methods tacked on to the resulting object (things such as treating ranges of records pulled like a hash, for instance. 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).
  - taf2 8y ago
    That is why we have pluck
    - throwaway427 8y ago
      Exactly. Use pluck, use exists, use count, use find_in_batches. Be thoughtful and have a culture of code reviews. Simple enough.
    - Rooster61 8y ago
      > 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 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.

PurpleRamen 8y ago

Mature is a humble way to describe stagnancy. Something/one has stopped growing and will likely never become better than it is now. This is on shortterm no decline, but will longterm evolve into it. 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.