Go Works: Episode 2 - The God Awakens
The taste of standardly formatted code, performance and concurrency zests has made the developing process as easy as a pie for both Software God and young disciple. The ingredients were fixed upon, the arguments were robust and straightforward, there were nothing else left on the planet Earth than to let the cooking marathon begin.
The process of an application development reminds of a cooking, whereas the programming code is the recipe. Distinctness and consistency are the two killers that fully and perfectly describe the most delicious meal recipe the one would think, meaning it is totally correct. The clearer the code, the faster the development and support processes are.
As Google company, the creator of Go, has large code base and gigantic amount of software stallions, the Go syntax was built as neat and simple as possible. That would give the software engineers a hand with maintaining and modifying the mentioned earlier codebase. Moreover, unlike other new programming languages’ syntax, Golang’s one has been unchanged and stable since the first release. To fully destroy the non-believer it is not a sin to bring up the “go fmt” tool, which comes from the language box. By pushing “go fmt” to the flashing LED iron box the code written in Go language will be formatted due to the “Golang Bible”, meaning every piece of the code will look the same everywhere, leading to software engineers feel safe about each other’s code style.
Cooking by the recipe is what makes the dish toothsome, nonetheless ingredients are what make the meal unbelievably savoury.
Concurrency model and central processing unit scalability bring the extraordinary aftertaste to the application meal. Whenever a chef lacks for processing some internal requests, it is attained conveniently thanks to the separate “goroutine” in the recipe. The goroutine consumes almost 2KB of memory from the heap, it is sixpenny comparing to the other programming languages’ resources usage, not to mention goroutines and operating system threads do not have 1:1 mapping, leading a goroutine to be run on multiple threads. Having stated that, the goroutines are multiplexed into the tiny amount of operating system threads on one pie’s side. By taking a bite of the other pie’s half, goroutines do have growable segmented stacks, with this in mind once the more memory is needed it will be occupied, until then the memory is not pawed, signifying Golang crosses the bridge only when it comes to it. This way millions of goroutines can be spinned whenever it pleases the chef and at any time throughout the recipe.
One of the most appealing moments in chef’s life is when the moulded recipe becomes Earth-known. Tons of prominent pies have been brought to the world since Golang appeared and the more remarkable ones are yet to come. Faithfully deserved Go’s vogue has not outflanked Ordnance Networks project where your humble servant has been building up the network weaponry and broadband termination platform along with the other software stallions.
All ingredients and the recipe considered, the picture is worth 1000 words and it whispers: “Good meals indulge people, the great ones bewitch”
Written by: Konstantin Yevchuk, Golang Software Engineer