Is Golang (Go) a good choice for Cryptocurrency application development?

When dealing with money, especially when dealing with a large amount of money involving a large number of transactions, that equals large amounts of processing power. How many large banks do you know of that have only one teller (physical person handling a physical transaction)?

I can’t think of any. Can you? It does not matter if the income was earned through stock investments or casino games. Large amounts of money equals large amounts of processing power.

Golang and concurrency programming

Most programming languages prior to Golang added concurrent development and Unicode as an afterthought. Golang was developed after Unicode was the standard and processing huge amounts of data outside of big government was not unexpected.

The result was that these features were put into the language specification from the very beginning, and it shows through the ease of use of these features. Golang is a pleasure to work in.

In C/C++ programs, there is one very large program that runs in one very large computer process. Image one physical bank teller handling every financial transaction that Slotocash casino has in a given day in sequential order, finishing the previous one before starting the next one.

Insane right?

But that is the way that a lot of traditional programs handle individual tasks within their application, even if the individual tasks are not dependent on each other. But that is not how it is in Golang.

Channels in Golang

Channels provide a way for two Goroutines to communicate with each other and synchronize their actions. Imagine two bank tellers working side by side.

One is handling debits while the other is handling credits. In the US, banks are required by law to process the credits before processing the debits. If a bank account has both debits and credits on a given day, the two tellers would need to communicate with each other.

But if a bank account only has debits or only has credits, the two tellers can work side by side without interfering with what the other teller is doing. The same is true with Goroutines (concurrent Go functions).

Channel direction in Golang

Channels handle the communication of messages from one goroutine to another goroutine.

Let’s look at our previous example of the two bank tellers who are handling credits and debits. For an account that has both credits and debits, “credit teller” must handle the credit transactions first, and then “debit teller” handles the debit transactions second.

The “debit teller” must know that the “credit teller” is finished before “credit teller” can start. But the “credit teller” does not need to even know that any debit transactions even exist, let alone if they are finished before starting the credit transactions.

In other words, there is a direction to the communication between the “credit teller” and the “debit teller” from the “credit teller” to the “debit teller”.

Select in Golang

Select statements are not something that exists in other programming languages. Select statements are switch statements that are specifically designed to handle channels.

Let’s say there is a third employee in our bank teller example called “print teller”. “Print teller’s” job is to print out the receipts that are handed to the customer. When the account is ready, “print teller” prints out the paperwork.

If “credit teller’s” customer has 1000 credit transactions and “debit teller” has 100 customers who have less than 5 transactions each, “debit teller” is going to handle a lot more customers than “credit teller” even though they are both handling the same number of actual individual transactions.

It would very unfair to make the 99 “debit teller” customers wait for the 1 “credit teller” customer to finish. So to be fair, the queue for “print teller” is not the same as the queue for either “credit teller” or “debit teller”. The only thing that “print teller” cares about is if the customer’s account is finished and the account is ready for printing.

Buffered channels

What happens when there is a backlog? “Credit teller” has finally finished with her 1 customer who had 1000 transactions and the account is finally ready to be printed. The account is handed off to “print teller” and “print teller” begins the work of printing out the receipt.

But what about “debit teller”. “Debit teller” is still chugging along with 100 customers who each have 1 – 5 transactions each. Does “debit teller” now have to wait for “print teller” to finish with the “credit teller” account? The answer is “no, not if the channels are buffered”.

“Dedit teller” can continue to send print requests to “print teller” and move onto the next customer without having to wait for “print teller” to finish.