Migrating from Ruby to Go: pros, cons, and how to get it right
A Ruby project worked steadily for years, but now the load is growing, response time is increasing, and colleagues are advising a switch to Go.
Let's explore this with Alexander Kirillov, a DevOps expert and mentor in the Evrone DevOps internship program.
What Go offers. Compilation to machine code – high performance under load. Goroutines simplify parallel computing, unlike Ruby with its GIL. Static typing catches errors at compile time. The final binary includes all dependencies – no runtime environment or gem management needed.
The downsides. The Ruby ecosystem (Rails, Active Record, gems) is significantly richer. Many things in Go would have to be written from scratch. Strict rules: an unused variable will prevent compilation. No classes or inheritance – only structs and interfaces. Migrating a large project takes months, plus retraining the team.
How to decide. Assess the real problems. If performance is no longer satisfactory – Go might help. If everything runs smoothly, the switch may not be worth the effort. The best approach: rewrite one microservice in Go first, rather than starting a revolution.
Want to try Go but unsure? We can help with migration – from a test prototype to a full project rewrite.
More details in the article: https://evrone.ru/blog/articles/from-ruby-to-go
A Ruby project worked steadily for years, but now the load is growing, response time is increasing, and colleagues are advising a switch to Go.
Let's explore this with Alexander Kirillov, a DevOps expert and mentor in the Evrone DevOps internship program.
What Go offers. Compilation to machine code – high performance under load. Goroutines simplify parallel computing, unlike Ruby with its GIL. Static typing catches errors at compile time. The final binary includes all dependencies – no runtime environment or gem management needed.
The downsides. The Ruby ecosystem (Rails, Active Record, gems) is significantly richer. Many things in Go would have to be written from scratch. Strict rules: an unused variable will prevent compilation. No classes or inheritance – only structs and interfaces. Migrating a large project takes months, plus retraining the team.
How to decide. Assess the real problems. If performance is no longer satisfactory – Go might help. If everything runs smoothly, the switch may not be worth the effort. The best approach: rewrite one microservice in Go first, rather than starting a revolution.
Want to try Go but unsure? We can help with migration – from a test prototype to a full project rewrite.
More details in the article: https://evrone.ru/blog/articles/from-ruby-to-go
❤5🔥2👏1
SberMegaMarket – 5 million products, 8 thousand sellers. At this scale, minor architectural flaws turn into real pain.
We joined as Go developers, mostly working on tasks for the SEO and advertising departments.
Reviews system.
We didn't just build a comment board – we built an engine with validation. A user writes a review, and the system checks: was it a real purchase? Is the content unique? Does it meet the "helpfulness" criteria? If yes – bonus rubles are credited. Everything is tied to Elasticsearch.
Photo gallery in reviews.
Previously, media was scattered. To see photos of a specific product, you had to dig through all the reviews. We aggregated everything into a single stream and created a unified access point.
Seller dashboard.
Vendors and brand representatives asked for the ability to respond to reviews – it didn't exist. We designed an account with this capability.
Advertising services.
Two of them: a campaign generator for Yandex.Direct and Google Ads, and an XML feed generator (products, prices, categories). Everything connects to external systems via API.
Brand aliases.
A brand can have a dozen spelling variations – Latin, Cyrillic, uppercase, lowercase. Previously, these sat statically in the database with no way to edit them. We built full CRUD – create, read, update, delete.
Stack.
Go (primary language), Elasticsearch (for reviews), Postgres, MS SQL, Redis, Vue.js, Gin, Go kit.
This isn't magic – just solid engineering. When the load is high, small things matter. We know how to handle that.
More technical details in the case study.👉 Link in the post.
We joined as Go developers, mostly working on tasks for the SEO and advertising departments.
Reviews system.
We didn't just build a comment board – we built an engine with validation. A user writes a review, and the system checks: was it a real purchase? Is the content unique? Does it meet the "helpfulness" criteria? If yes – bonus rubles are credited. Everything is tied to Elasticsearch.
Photo gallery in reviews.
Previously, media was scattered. To see photos of a specific product, you had to dig through all the reviews. We aggregated everything into a single stream and created a unified access point.
Seller dashboard.
Vendors and brand representatives asked for the ability to respond to reviews – it didn't exist. We designed an account with this capability.
Advertising services.
Two of them: a campaign generator for Yandex.Direct and Google Ads, and an XML feed generator (products, prices, categories). Everything connects to external systems via API.
Brand aliases.
A brand can have a dozen spelling variations – Latin, Cyrillic, uppercase, lowercase. Previously, these sat statically in the database with no way to edit them. We built full CRUD – create, read, update, delete.
Stack.
Go (primary language), Elasticsearch (for reviews), Postgres, MS SQL, Redis, Vue.js, Gin, Go kit.
This isn't magic – just solid engineering. When the load is high, small things matter. We know how to handle that.
More technical details in the case study.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤5🔥4👍1
There is no single "right" framework in Go. And that's perfectly fine.
Some need a lightweight router with nothing extra. Others need a heavy MVC with ORM, authorization, and code generation. The choice depends not on trends but on the task: microservices, highload, monolith, MVP, or enterprise.
A Go framework doesn't make code "magically better." It just takes care of the routine: routing, JSON handling, validation, logging. That saves development hours and reduces the number of bugs. Plus, a new developer will get up to speed faster if the project uses a popular tool.
Next up – a quick overview of the most common options. What works for which task, how they differ, and where they might shine or just get in the way. A detailed breakdown is available in the article on our website: https://evrone.com/blog/best-golang-frameworks-2025
Some need a lightweight router with nothing extra. Others need a heavy MVC with ORM, authorization, and code generation. The choice depends not on trends but on the task: microservices, highload, monolith, MVP, or enterprise.
A Go framework doesn't make code "magically better." It just takes care of the routine: routing, JSON handling, validation, logging. That saves development hours and reduces the number of bugs. Plus, a new developer will get up to speed faster if the project uses a popular tool.
Next up – a quick overview of the most common options. What works for which task, how they differ, and where they might shine or just get in the way. A detailed breakdown is available in the article on our website: https://evrone.com/blog/best-golang-frameworks-2025
🔥4👍3❤1
Large streaming services have one particular characteristic: you almost can't just "rewrite" them properly. While developers change the architecture, the product keeps living – people watch shows, streams go live, new releases come out, marketing runs special projects. Everything has to keep working simultaneously.
Our work with mоre tv and CTC's platforms wasn't a "we built a cool new service from scratch" story. It was about a rather painful transition from a heavy legacy system to an architecture that could be properly maintained going forward.
The project had a lot of what typically accumulates over the years at large media platforms: a Rails monolith, tightly coupled services, shared databases, a large number of integrations, and infrastructure that was already difficult to change without risking breaking something.
Projects like this always highlight the gap between "ideal" architecture and real-world development. In theory, everyone loves rewriting from scratch. In practice, you're more often carefully disassembling a functioning airplane mid-flight: https://evrone.com/cases/ctc-moretv
Our work with mоre tv and CTC's platforms wasn't a "we built a cool new service from scratch" story. It was about a rather painful transition from a heavy legacy system to an architecture that could be properly maintained going forward.
The project had a lot of what typically accumulates over the years at large media platforms: a Rails monolith, tightly coupled services, shared databases, a large number of integrations, and infrastructure that was already difficult to change without risking breaking something.
Projects like this always highlight the gap between "ideal" architecture and real-world development. In theory, everyone loves rewriting from scratch. In practice, you're more often carefully disassembling a functioning airplane mid-flight: https://evrone.com/cases/ctc-moretv
👍6🔥6❤5
Flutter or native? Each approach has its fans who are ready to argue until they're blue in the face. But outside of internet battles, the choice usually comes down to three things: how much time to launch, how much money for maintenance, and what kind of experience users need.
In the cards – our version of the pros and cons, without trying to declare a winner.
And now a question for those who actually write code or make decisions: what do you choose for new projects and why? Not abstractly "in general," but in practice. Your actual opinion is what matters.
In the cards – our version of the pros and cons, without trying to declare a winner.
And now a question for those who actually write code or make decisions: what do you choose for new projects and why? Not abstractly "in general," but in practice. Your actual opinion is what matters.
❤5🔥4👍3