Codementor Events

What are the practice proven cases when it is a good or bad idea to use Go for the project's backend (+some lover insights)

Published May 21, 2018Last updated Nov 17, 2018
What are the practice proven cases when it is a good or bad idea to use Go for the project's backend (+some lover insights)

Preamble

(You can just start reading from "The Core" part below.)

It is half to 2 AM, and my baby finally went to sleep. I wish he had gone a bit earlier when I wanted to sleep as well. But now the moment has passed, so I just started to scroll the Quora Digest, lurking for some interesting information (which it is always full of), and my view has stopped at a question from someone: "What's the best thing about GoLang?"

My curiosity was: what kind of person is the one who wrote that question? Is he a young programmer who is choosing a path? Is he just a geek who follows development trends? Or some developer for another technology who reviews what's happening? Or perhaps he is a founder of some startup that has been advised to use this technology in his project and he's reaching out to the collective mind in order to make a decision for whether this makes sense?

I realized suddenly that what whoever asked the question actually wanted to know is whether he needs to use Go for something or not. For something: what? For learning? Or for some project? It is not important, because it is related to the application. You may think you will learn/use the language, but with that, you have to learn the domain as well and apply your knowledge as a toolset to solve particular tasks, just like you use a screwdriver of the proper size for the corresponding screw.

So basically, I'm just duplicating my answer here, with some improvements and a wider overview of the topic.

The Core

The practice shows that in the case of Go, there are two important areas where it works the best. It is totally not limited to, but its strengths reveal, the most brightly within them.

The first is high load projects which should survive hundreds of thousands and millions of either requests (in case of HTTP protocol) or simultaneous connections (in case of persistent connections like Websocket). Go enables to do that very cheap and ridiculously easy in terms of the amount of code and involved technologies, thanks to its effectiveness, native application (it is deployed as a binary, unlike many other languages), and built in convenient parallellism architecture provided by goroutines and channels.

In some cases, you can gain a performance like that you’ll be possible to replace 100 servers with 10 ones. You can read this great article “Handling 1 Million Requests per Minute with Go” to see how awesome it does the job in this case. There also was a Twitter (real life?) joke about Go from Rob Pike, the language’s designer: “A Google org once complained their rewrite from Java to Go had made things 10X slower until they noticed the graph was in micros not millis”. 😃

And the second area in which it is used even more often is cryptocurrency related projects (and blockchain related in general). Why? Well, first of all the previous reason: performance. It is a high demand at the moment for the crypto exchanges. There are a lot of existant exchanges like Bittrex, Poloniex, etc., and the ones which just aggregate all of them.

They still keep appearing, as well as the currencies, and all of them should process things really quickly because say you have an order book, and you receive many new orders both for buy and sell from different sources which you have to add to the order book, and you have to match and execute the orders very quickly but still keep consistency of the order book, like don’t execute the same order twice. So you again need parallellism, performance ,and scalability. But, besides that, cryptocurrency (and any trading related, in fact) projects are much more convenient to write using the language with static strong typing, which is provided by Go.

Besides of all that, I would mention some minor and quite opinionated things, like that it is fun writing on Go because it has a very easy to learn and minimalistic syntax that somehow “follows” your programming logic. For example, say, you write like:

var variableName bool = true

First, you need a variable, so you put var. Then you fix its name and you don't waste anymore the brain's fuel to choose the name (there's not much "fuel" that you would waste, but still a bit). Then you think only about the logic, so you put the data type (bool) and initialize the variable.

When in the context of coding, during some function's body, you would also want to just init some variable fast, for example based on some other function call result. And you absolutely could do that, just as simple as:

dataSourceName := fmt.Sprintf("%s:%s@tcp(%s)/%s?parseTime=true", config.DbUser, config.DbPassword, config.DbHost, config.DbName)

Go also has an awesome logic of memory allocation for the slices (you can read this good article “Collections of unknown length in Go” about that) which is effective, and you don’t have to think all the time about how that works. You can just use slices for a bigger amount of tasks and you have to think a bit less regarding the choosing of the proper data structure.

There are also various minor things that the language has by design and which are interesting and useful.

I've explained when and why it is good to use Go. So now, what are the cases when you really should NOT use Go?

The answer is simple. When you can't afford to look for a programmer for more than two or three business days, and/or when the hourly rate is crucial for you. This typically happens at startups, when you have to write things really quickly just to build your MVP and go live.

Once you gain some clients and raise investments, you would be able to rewrite and improve anything you need. If the number of users grow, you always will be able to write your back-end in Go. By the way, this is a good point of why you should think about the possible use of the Microservice Architecture from the very beginning, to rewrite then only the really needed things in future. But when you are really limited in resources and time, you should use the most widespread and cheap (in terms of developer's time cost) technology, like PHP or Node.js.

So that's my point regarding this, and I really hope this could be useful for someone.

Discover and read more posts from Illia Kharytonov
get started
post commentsBe the first to share your opinion
Show more replies