Go — Learnings!!

‘Tell me and I forget. Teach me and I remember. Involve me and I learn.’–Benjamin Franklin.

Hey ya’ll! This post is going to be about Go — A programming language which is famous for its most meteoric rise in distributed applications. I used this language in an internal project and it was an enjoyable learning experience. I will talk about what Go as a programming language brings to the table and how applications running distributed-ly can avoid common pitfalls if built in Go.

Let’s dive deep right into it. The most basic feature of Go is support for CSP (Communication-Sequential-Processing) based concurrency, built-in testing and profiling framework and oh, of course, easy and clear documentation. Google developed and launched “Go” with the primary focus of using Go for cloud based or server-side applications. But because of its simplicity and easy-to-understand spec, Go has seen a meteoric rise in recent times and is being used across companies in the world of artificial intelligence, data science, dev-ops and CLI tools. Go also provides the support for Structural Typing, Memory Safety and Garbage Collection. These are some of the major benefits of using Go, but I will keep this post to the lessons which I learnt while implementing the leader election in the distributed application.

As already discussed, the benefits of a leader in a distributed system are indispensable. We already have a publically available implementation of DDB Lock Client in Go by Cirello. But the implementation I worked on was an internal implementation which was being used company wide. I brought about a feature parity in that implementation and used that in the application to elect the leader. Let’s see how using Go in the application was better than using the same in Java.

The locking protocol implemented using DDB guarantees expiration prevention as automatic updates on an attribute (Record Version Number) in the table. The Go implementation achieved this by spawning background go routines as compared to java implementation, which spawned background OS threads. This brought about the major benefits of using Go routines, which are:

• Management by go runtime as opposed to kernel (for threads)
• Economy for the stack size (go routines can grow and shrink but threads have a fixed size)
• Latency benefits as go routines communicate with lower latency as opposed to threads.

The application I was building was using container based deployments. We chose containers keeping in mind the benefits of containers:

• Less management in terms of system resources. (No OS images included).
• Portability across machines as no “Works on my machine” errors.

Go, unlike Java, compiles into a single binary executable. We deal with the dependencies at the build time. The executable runs like a race-horse at the run-time with no dependencies and libraries to manage. This feature couples with the benefits provided by containers, made building the application in Go a very delightful experience.

These were some of the basic teachings I can recall from my time building the application. I will be more frequent with my encounters with different programming languages as I dive deep into the world of distributed systems. Signing off for now. Ciao! — AD