How to kill a dragon: Rewriting your app to Golang
--
Let’s imagine that your application is written in some scripting language — e.g. Ruby — and you want to rewrite it in Go. You may ask a reasonable question: what is the point in rewriting a program that is up and running?..
Why?
Firstly, let’s assume that your program is connected to a certain ecosystem. In our case, the ecosystem includes Docker and Kubernetes. The entire infrastructure of these projects is written in Golang. By rewriting our program in Go, we get access to libraries used by Docker, Kubernetes and other projects. Basing your product on the existing infrastructure of main projects, you facilitate its support, development, and refinement. You’re getting immediate access to all new features without the need to rewrite them to another language. In our particular situation this reason alone was enough to decide on changing the language and to choose the language. Besides, there are some other advantages…
Secondly, we admire the simplicity of installing Go applications. There is no need to install RVM, Ruby, a set of gems, etc. You just download single binary file and run it.
Thirdly, Golang programs tend to work faster. And I am not talking about a significant increase in speed in any language which comes from using appropriate architecture and algorithms. It is about the boost that you can literally see and feel when running your program in your shell. For example, running --help in Ruby takes around 0.8 sec. The same command in Go is executed in 0.02 sec. It’s easy to see a noticeable improvement in user experience.
Main challenges
Okay, you can just write new code from scratch, making it completely isolated from the old one. This way you immediately face some restrictions and difficulties in terms of the time and resources allocated to this development:
- The current version of the program in Ruby is in constant need for improvements and corrections:
- Bugs occur all the time, and they have to be fixed promptly;
- You can’t stop implementing new features since they are often demanded by the users/customers.
2. Maintaining 2 codebases at the same time is difficult and expensive:
