Sorry, but this article makes no worthwhile argument for why RoR devs should consider Go, it's just circle jerk.<p>> The main approach to resolve performance and stability issues in an established system, as well as team scalability problems, is to split the monolithic kernels into a set of microservices.<p>For one, this goes against the idea of having a monolith and all the benefits that has. SOA trades one set of problems for another, and requires an organizational and cognitive shift in approach.<p>> Go excels when projects get into phase when everything should be calm and steady.<p>So does Ruby? And also when it's not.<p>> you may want to think about adding Go into the stack to take care of the most complex code while the remaining Ruby/RoR stack provides an older but solid website engine<p>"older but solid". THat's a disingenuous attempt at calling rails obsolete or legacy - neither of which, in any way, it is.<p>> Go is fresh<p>Oh I see where we're going with this now.<p>> it’s also important to think about what’s going to happen with the project in the next couple of years. Every technology that exists on the market has its own lifespan and a couple of target problem domains where it’d be the best solution to use.<p>Yes, you should be thinking of the long term - of the project you're building. Go might very well be a good choice for your problem domain, but for most startups they simply do not need it. Keeping everything in the same stack/language makes it more portable between devs and easier to reason about. When you start rolling up your sleeves and creating custom stuff like Go SOA; you lose that and the complexity of the service amplifies. It also means you now have to hire rails + Go devs.<p>Go is a lower level language. You have to write a lot to do the basics that, in ruby/rails, are just a method call away. This is not a free trade off or anywhere close to 1:1 on the productivity that this article claims. Yes, there are benefits to Go and for certain types of work it does well. But for literally 95% of the workloads out there, a set of background workers executing jobs does perfectly well up to some very large scales.<p>on a personal note, what draws me to ruby/rails does not appear in Go. It's a different language, different "culture" (or lack of), and different mindset on work and what should & should not be. It's more.... google.<p>Anyway, Go is the right choice in some situations. But for most, just stick with ruby on rails until you really start hitting growing pains. Shopify does 80K Requests PER SECOND on a rails stack.