Hacker News Reader

Comment by revskill | Hacker News Reader

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.

View on HN

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.

The Rails way to scale is caching. In your case, Rails has something called Fragment caching.

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.

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.

Caching. There are multiple layers of caching in rails, including caching of rendered views/partials.

Reply on news.ycombinator.com