Before Go, many companies used RoR as their primary framework for quick prototyping and placing their solution on the market as quickly as possible. To this day, RoR continues to win the position of being the most feature-rich and productive web framework. But sometimes, using an old instrument like RoR for anything new can cause some problems.
The emergence of Go has overshadowed Ruby in the current marketplace. Go, designed by Google, is a strongly-typed programming language that is oriented on performance, concurrency, and developer effectiveness.
In this article, we’ll provide four strengths and weaknesses of the Go programming language and its frameworks in comparison with Ruby and Rails. You may even find that Go could complement what’s missing in RoR applications. So if your team is working with a RoR framework and is experiencing any problems, consider adding Go to your stack.
Go Out Performs RoR
Because Go is a compiled language and one of its primary goals concerns the runtime performance that must be close to C and Java, the programs are usually somewhere between 10-to-100 times faster than the corresponding Ruby programs. In many cases, the performance of Ruby is still viable — like when the database of small-to-midsize online shops usually represents the main bottleneck of the whole system. However, any application that succeeded in terms of site traffic would discover that its performance degraded with growth, especially in hot paths of the code.
These companies rewrote the code, split the codebase apart, and moved high-loaded parts outside the Ruby/RoR environment. For instance, a company called IronMQ moved from Ruby to Go and reduced the amount application servers from 30 to just two.
If your application is going to grow in the near future, it’s important to consider adding performance-oriented languages such as Go to your stack. Furthermore, this decision should be made sooner rather than later in order to have enough time to find and train a team of developers to address the problem.
API and Data Strictness of Go
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. This creates a Service Oriented Architecture (SOA). Many of Rails applications tend to be continued from the early 2000s by monolithic tradition. But nowadays, there’s a strong demand to move to independent services developed by different teams as early as possible to avoid scale issues.
The SOA approach requires that services are communicating with each other. Thus, a strict API definition must be created. A data structure design should also be considered to avoid in-flight data corruption or misinterpretation. Go has been designed to be statically typed and sets a high bar for data schema strictness. When choosing to add microservices in Go, you’re sacrificing productivity and flexibility to guarantee that the resulting API and data layout will be as strict as possible and, in most cases, self-documenting.
In Go versus Ruby debates, it’s often noted that Go’s syntax is less flexible and very strict, which affects the developer’s productivity. However, it leads to more maintainable code and less time spent in the debugging process.
Initial Cost of Development Versus Maintenance Cost
Go is an extremely productive language when it comes to maintenance and retaining stability under higher loads. The Rails framework may reduce the initial cost of development and offer greater speed with numerous boilerplate-generated code. However, Go excels when projects get into phase when everything should be calm and steady.
All components that Go has out of the box are orthogonal and easily composable. This means that complex stuff can be solved by combining a set of small and simple components by hand. Furthermore, by adding those to the mix, it won’t destabilize the remainder of the system.
In any long-term project, maintenance should be taken into serious consideration. So if you plan to expand your system, consider using Go for new services based on the ratio of the initial development effort to the maintenance effort in the future.
Concurrent Programming
Concurrent shared-memory access can be avoided for simple applications that are approaching the MVP stage for the first time. However, as the project expands and the complexity increases, developers may experience new problems on their agenda. Different instruments are required to solve these issues.
Shared-memory synchronization, readers–writers locks, and in-memory queues are necessary to create a system that will cover complex scenarios. Ruby supports these examples, but it wasn’t explicitly designed for these tasks. Implementing code that heavily relies on concurrency can be counterproductive and more difficult to debug. Unfortunately, Rails won’t provide any boilerplate solutions in order to solve computer-science related problems.
When dealing with Go, the language has been designed with concurrency and all these related problems in mind. Therefore, it’s very productive to write concurrent code in Go and not more difficult to debug any existing code. If your project evolves from a simple e-shop to a complex dynamic system, 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.
Conclusion
Go is fresh and has been crafted while taking into consideration all known downsides of the existing programming language environments. It has many crucial qualities to offer out of the box. Unfortunately, it doesn’t have much power to build web sites rapidly in comparison to Ruby and its Rails framework. However, Go provides plenty of features that may improve code quality as well as developer’s productivity while reducing the cost of development in long run. All of these similar methodologies appeared in Ruby only after a decade of this language’s existence. Furthermore, Ruby depended on the community rather than the language core team, unlike Go.
When selecting a technology, the approach must not be rushed. Choose a technology that is wise, rational, and coherent. Try to avoid falling for trendy technologies that shine for a couple of years and then fizzle out. Not every language or framework that tries to replace Ruby on Rails will win a prime place under the sun.
At Sphere Software, we continually monitor the technologies that other companies are using. Nowadays, it’s clear that Go has won a major share in the current technology stack. Eventually, we believe that hiring Go developers will be as easy as hiring Ruby developers. Consider solving different problems with the appropriate tools and try to check out Go as early as possible.
We believe any programming language should be chosen by taking a particular problem into consideration. But 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.
