3 ms·
Ruby is OOP. Go is procedural. They're different.
by revskill 4y ago
Ruby is OOP.
Go is procedural.
They're different.
- deleted 4y ago[deleted]
- moomoo11 4y agoI know. I'm asking why someone would choose rails to build software (a company) than something like Go which is IMO easier to learn and way easier to actually manage.
- revskill 4y agoRuby 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 agothanks. 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 agoThe 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 agoAh 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 agoThe Rails way to scale is caching. In your case, Rails has something called Fragment caching.
- moomoo11 4y agoI 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 agoFWIW, 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 agoCaching. There are multiple layers of caching in rails, including caching of rendered views/partials.
- BillSaysThis 4y agoEasier for you is hardly easier for everyone.