3 ms·

Could you share some examples of this? I am a bit over >1 year with Rails and I don't see this to be the case. There is some "group think" perhaps, but every e

Could you share some examples of this? I am a bit over >1 year with Rails and I don't see this to be the case. There is some "group think" perhaps, but every ecosystem has that (Whats the "pythonic" way or Java way to write x). I work at Shopify which uses Ruby and Rails extensively, and I don't think things have "gone off the rails". We use other technologies where appropriate, but for the core business logic cases, Rails is fantastic.

ulizzle 4y ago
You have to measure by time-to-market / team size. How much it costs to maintain the system, how long it takes to ship features, fix bugs, reach milestones, etc; which is something you can't say publicly, and even if the company did, it would be heavily doctored to make a good impression on stakeholders. That's why I think the argument is a weak appeal to authority. Throw enough money at a problem, and you can scale anything involving computers. Notice how expensive is Heroku. But you can't add more team members to a project and expect things to go faster, which is where the real problem with Rails lies.
- jemmyw 4y ago
  I've worked at a number of places using Rails and places using other languages. I cannot square your argument with my experience. The place I currently work has a 10 year old Rails monolith, less than 50 developers (I joined at ~10 devs) and features are still shipped very quickly. I would say that the Rails framework is one aspect of several that has allowed the company to ship fast and be very profitable without having to grow the engineering team massively. I've worked places where we've made a complete mess out of Java or .NET code. You might be correct that there is a degree of group think within Rails developers, but that's actually a good thing because they don't deviate too far away from a set of conventions for writing their code, which causes less mess. And they at least know what a convention is and stick to it once you agree on it. At one point in my career I thought I had put Rails behind me because it's not that compatible with services that are supposed to be more scalable. However, this again goes against your argument, I saw just how much overhead was being generated by that kind of architecture. Yes you could have way more developers working on the product, but they weren't working on deliverable features, they were working on integrating with the rest of the system. I'm sure there are team scalable limits to Rails. I've noticed though that as our product has become more complex more of the code needs to be frontend in order to support that interface complexity and so perhaps that team limit can actually be stretched out a very long way. Caveats: I think Rails is good and I'm defending it because I think the argument made here is bunk, but I'm sure there are Rails codebases that are a complete mess. I've pointed out other languages where I've seen issues, but I've also seen great codebases in those languages, so it's not a knock against them in particular. I'm not opposed or for any particular architecture, my experience is just that something like Rails can get you started much faster and can scale much further than a subset of devs seem to think.
  - ulizzle 4y ago
    Just because you can’t square it with your experience doesn’t mean much. What you want to do is compare your experience with others. Rails can work well but it’s going to be expensive. Everything is a trade-off. Because Devs don’t see operating costs, they don’t feel the pain.
    - jemmyw 4y ago
      Seeing as developer salaries are the biggest cost and I just talked about how I've seen fewer developers deliver more over significant time with Rails your comment doesn't make any sense. Anyway both of our opinions are based on anecdote. It would be interesting to see an analysis on real data but I wouldn't trust that anyone could get that data from industry, correctly accounting for failures.
  - 0xblinq 4y ago
    Your experience matches mine. 100% agree on this.
- 0xblinq 4y ago
  Those metrics you’re asking for, I’ve seen them to vary wildly within the exact same stack at different companies, or even within the same company at different teams. I don’t think they have anything to do at all with the stack. I think they’re more related to the people, the working culture, the practices and in particular the rotation and the “happiness” within the team
bdcravens 4y ago
The sheer amount of tooling that Shopify has built to overcome this is a good example. https://shopify.engineering/shopify-made-patterns-in-our-rails-apps https://shopify.engineering/shopify-made-patterns-in-our-rai... "Going off the rails" isn't an indication that Rails is bad, as much as a claim that it can't fit the needs of a company with either splitting to other technologies ("We use other technologies where appropriate") or painting outside of the Rails lines.
- ecshafer 4y ago
  Any company at scale develops these other solutions to help scale. A company using Java and Spring does the same or C++ or whatever. Shopify seems to be unique at the largest (I think) Ruby/Rails shop, so they are leading the way developing a lot of these tools. I don't think that its significantly different than Google making Guava, Map Reduce, etc.
  - bdcravens 4y ago
    Most companies are nowhere near a Shopify or a Google. I think it's totally fair to to admit that Rails is just one of many equivalent solutions that will eventually require scale out in a complementary technology, but that's not the sales of pitch of Rails.
  - eek2121 4y ago
    Bandcamp and hey aren't scalable? Like, I am the first person to be pessimistic about a framework or language, but I've been working with both Ruby and Rails since 2007. Every single company that has strayed outside the defaults in the name of 'making a scalable app' has spent tons of money in tech debt, maintenance, etc. Yet the companies that stayed on the tracks had very few issues with scalability or tech debt. I think pretty much all developers seem to forget that when you bring in a third party library or a unique pattern, you also inherit maintenance in both those areas. The problem isn't the language or framework, the problem is that developers try to solve problems by deviating from tested and proven methods. "Convention over configuration" is what Rails is built around. Why do so many people prefer configuration over convention? Why not just pick another framework, or possibly even language if you are going to do this? Note that I'm not affiliated with Rails, companies financially affiliated with Ruby and/or the Rails framework, and have no desire to be. I just like building awesome stuff.
eek2121 4y ago
Do you use RSpec? Devise? etc. There is your example.
mplewis 4y ago
Out of the box, Rails apps typically suffer from testability issues with fat models, problems caused by overuse of OOP patterns, and “ball of mud” lack of separation of domains. There are many ways to solve these problems with gems and specific disciplinary patterns, but Rails does not go out of its way to show them to you. Most people find their way out of the problems only after they are deep into them.
- 0xblinq 4y ago
  This is not specific to rails, at all. It can happen with any stack you use. If you prefer building on top of some minimalist framework, then it’s very likely you end up with worse problems. If you don’t because you’re an excellent programmer, then you wouldn’t have had those problems with rails either. It’s not the tools what make things a mess or a great piece of art. It’s the people using it.

ulizzle 4y ago

You have to measure by time-to-market / team size. How much it costs to maintain the system, how long it takes to ship features, fix bugs, reach milestones, etc; which is something you can't say publicly, and even if the company did, it would be heavily doctored to make a good impression on stakeholders. That's why I think the argument is a weak appeal to authority. Throw enough money at a problem, and you can scale anything involving computers. Notice how expensive is Heroku. But you can't add more team members to a project and expect things to go faster, which is where the real problem with Rails lies.

jemmyw 4y ago
I've worked at a number of places using Rails and places using other languages. I cannot square your argument with my experience. The place I currently work has a 10 year old Rails monolith, less than 50 developers (I joined at ~10 devs) and features are still shipped very quickly. I would say that the Rails framework is one aspect of several that has allowed the company to ship fast and be very profitable without having to grow the engineering team massively. I've worked places where we've made a complete mess out of Java or .NET code. You might be correct that there is a degree of group think within Rails developers, but that's actually a good thing because they don't deviate too far away from a set of conventions for writing their code, which causes less mess. And they at least know what a convention is and stick to it once you agree on it. At one point in my career I thought I had put Rails behind me because it's not that compatible with services that are supposed to be more scalable. However, this again goes against your argument, I saw just how much overhead was being generated by that kind of architecture. Yes you could have way more developers working on the product, but they weren't working on deliverable features, they were working on integrating with the rest of the system. I'm sure there are team scalable limits to Rails. I've noticed though that as our product has become more complex more of the code needs to be frontend in order to support that interface complexity and so perhaps that team limit can actually be stretched out a very long way. Caveats: I think Rails is good and I'm defending it because I think the argument made here is bunk, but I'm sure there are Rails codebases that are a complete mess. I've pointed out other languages where I've seen issues, but I've also seen great codebases in those languages, so it's not a knock against them in particular. I'm not opposed or for any particular architecture, my experience is just that something like Rails can get you started much faster and can scale much further than a subset of devs seem to think.
- ulizzle 4y ago
  Just because you can’t square it with your experience doesn’t mean much. What you want to do is compare your experience with others. Rails can work well but it’s going to be expensive. Everything is a trade-off. Because Devs don’t see operating costs, they don’t feel the pain.
  - jemmyw 4y ago
    Seeing as developer salaries are the biggest cost and I just talked about how I've seen fewer developers deliver more over significant time with Rails your comment doesn't make any sense. Anyway both of our opinions are based on anecdote. It would be interesting to see an analysis on real data but I wouldn't trust that anyone could get that data from industry, correctly accounting for failures.
- 0xblinq 4y ago
  Your experience matches mine. 100% agree on this.
0xblinq 4y ago
Those metrics you’re asking for, I’ve seen them to vary wildly within the exact same stack at different companies, or even within the same company at different teams. I don’t think they have anything to do at all with the stack. I think they’re more related to the people, the working culture, the practices and in particular the rotation and the “happiness” within the team

bdcravens 4y ago

The sheer amount of tooling that Shopify has built to overcome this is a good example. https://shopify.engineering/shopify-made-patterns-in-our-rails-apps https://shopify.engineering/shopify-made-patterns-in-our-rai... "Going off the rails" isn't an indication that Rails is bad, as much as a claim that it can't fit the needs of a company with either splitting to other technologies ("We use other technologies where appropriate") or painting outside of the Rails lines.

ecshafer 4y ago
Any company at scale develops these other solutions to help scale. A company using Java and Spring does the same or C++ or whatever. Shopify seems to be unique at the largest (I think) Ruby/Rails shop, so they are leading the way developing a lot of these tools. I don't think that its significantly different than Google making Guava, Map Reduce, etc.
- bdcravens 4y ago
  Most companies are nowhere near a Shopify or a Google. I think it's totally fair to to admit that Rails is just one of many equivalent solutions that will eventually require scale out in a complementary technology, but that's not the sales of pitch of Rails.
- eek2121 4y ago
  Bandcamp and hey aren't scalable? Like, I am the first person to be pessimistic about a framework or language, but I've been working with both Ruby and Rails since 2007. Every single company that has strayed outside the defaults in the name of 'making a scalable app' has spent tons of money in tech debt, maintenance, etc. Yet the companies that stayed on the tracks had very few issues with scalability or tech debt. I think pretty much all developers seem to forget that when you bring in a third party library or a unique pattern, you also inherit maintenance in both those areas. The problem isn't the language or framework, the problem is that developers try to solve problems by deviating from tested and proven methods. "Convention over configuration" is what Rails is built around. Why do so many people prefer configuration over convention? Why not just pick another framework, or possibly even language if you are going to do this? Note that I'm not affiliated with Rails, companies financially affiliated with Ruby and/or the Rails framework, and have no desire to be. I just like building awesome stuff.

eek2121 4y ago

Do you use RSpec? Devise? etc. There is your example.

mplewis 4y ago

Out of the box, Rails apps typically suffer from testability issues with fat models, problems caused by overuse of OOP patterns, and “ball of mud” lack of separation of domains. There are many ways to solve these problems with gems and specific disciplinary patterns, but Rails does not go out of its way to show them to you. Most people find their way out of the problems only after they are deep into them.

0xblinq 4y ago
This is not specific to rails, at all. It can happen with any stack you use. If you prefer building on top of some minimalist framework, then it’s very likely you end up with worse problems. If you don’t because you’re an excellent programmer, then you wouldn’t have had those problems with rails either. It’s not the tools what make things a mess or a great piece of art. It’s the people using it.