Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I 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.



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.


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.


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.


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.


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


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.


Easier for you is hardly easier for everyone.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: