3 ms·

Ruby provides a complete hackability/customization framework for you to use. So library locked-in is out of place. For example, you use a library which gives y

Ruby provides a complete hackability/customization framework for you to use. So library locked-in is out of place. For example, you use a library which gives you 99% of functionalities you want. Now there's a 1% use case you want different behaviour and you can't directly modify library code. There's an escape hatch here, it's Ruby. It's like "fork" on steroid. Why Rails ? Because it's the "only" web framework in Ruby. No second choice for large scale application.

moomoo11 4y ago
thanks. one more question - from a cost perspective, again I'm not super experienced in rails but enough to debug production issues and ensure stuff works - I recall that for this one rails application, there were like 30 instances of it running on some beefy configurations and it was getting hammered quite a bit. We saw it was only able to manage like 300 req/second. A lot of time was spent rendering the template, like a few ms. I ported that thing to Go and it takes microseconds to render a template. A single Go application running on cheap, shared configuration can handle like 10x the traffic.
- revskill 4y ago
  The de-factor Ruby/Rails way to application development is DRY. DRY everything if possible, performance is not 1st priority. Less code >> more performant in general use case. TL;DR is: Vendor lock in vs performance lock in. It's hard to not have both at once.
  - moomoo11 4y ago
    Ah I see. How do rails-first places handle performance issues, such as this template rendering issue? I'm curious to know what I could have done differently than a re-write.
    - revskill 4y ago
      The Rails way to scale is caching. In your case, Rails has something called Fragment caching.
      - moomoo11 4y ago
        I see. But that would increase memory usage no? I'll look into it, thanks. And I understand now, the priority is not to chase high performance but have some set of standards that you can adopt without to much bike shedding. I still am not convinced to use rails over Go for my needs, but I am glad you helped me get some more insight.
        zdragnar 4y ago
        FWIW, my experience on projects with a rails backend is it makes it really easy to fall into performance traps. Active Record is especially bad at encouraging N+1 queries, though the same could be true of many ORMs. A second issue is that if you come from a background where everything is either explicit or obvious, you are in for a world of hurt. I've seen senior developers try to figure out where a particular method is defined by setting a breakpoint, connecting a REPL, then invoking some special methods to get Ruby to tell them the file and line for the source definition. It is just a different way of developing, and (personally) I think the reputation is a bit cult-ish.
    - jaxn 4y ago
      Caching. There are multiple layers of caching in rails, including caching of rendered views/partials.

moomoo11 4y ago

thanks. one more question - from a cost perspective, again I'm not super experienced in rails but enough to debug production issues and ensure stuff works - I recall that for this one rails application, there were like 30 instances of it running on some beefy configurations and it was getting hammered quite a bit. We saw it was only able to manage like 300 req/second. A lot of time was spent rendering the template, like a few ms. I ported that thing to Go and it takes microseconds to render a template. A single Go application running on cheap, shared configuration can handle like 10x the traffic.

revskill 4y ago
The de-factor Ruby/Rails way to application development is DRY. DRY everything if possible, performance is not 1st priority. Less code >> more performant in general use case. TL;DR is: Vendor lock in vs performance lock in. It's hard to not have both at once.
- moomoo11 4y ago
  Ah I see. How do rails-first places handle performance issues, such as this template rendering issue? I'm curious to know what I could have done differently than a re-write.
  - revskill 4y ago
    The Rails way to scale is caching. In your case, Rails has something called Fragment caching.
    - moomoo11 4y ago
      I see. But that would increase memory usage no? I'll look into it, thanks. And I understand now, the priority is not to chase high performance but have some set of standards that you can adopt without to much bike shedding. I still am not convinced to use rails over Go for my needs, but I am glad you helped me get some more insight.
      - zdragnar 4y ago
        FWIW, my experience on projects with a rails backend is it makes it really easy to fall into performance traps. Active Record is especially bad at encouraging N+1 queries, though the same could be true of many ORMs. A second issue is that if you come from a background where everything is either explicit or obvious, you are in for a world of hurt. I've seen senior developers try to figure out where a particular method is defined by setting a breakpoint, connecting a REPL, then invoking some special methods to get Ruby to tell them the file and line for the source definition. It is just a different way of developing, and (personally) I think the reputation is a bit cult-ish.
  - jaxn 4y ago
    Caching. There are multiple layers of caching in rails, including caching of rendered views/partials.