Ruby is OOP.
Go is procedural.
They're different.
Go is procedural.
They're different.
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.
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.
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.
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.
I still am not convinced to use rails over Go for my needs, but I am glad you helped me get some more insight.
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.