Marcin Kuthan

Marcin Kuthan

Big data engineer leading @allegro real-time, highly scalable and fault-tolerant data ingestion platform. It processes a few billion events every day with e2e latency below one minute.

Go is a modern programming language designed at Google to improve developer productivity. But how to improve productivity? By limiting engineers’ power and flexibility 😂

Why did I choose to learn Go?

  • After Software Engineering at Google lecture I wanted to check if Go is truly so fantastic.
  • Learning a new language is always good for your personal software engineering toolbox, especially if the language is distinctly different from what you already know.

After quick look at Reddit I realized that Go is a controversial language: What do you like about Go?, Why do people hate Go?. But in general one opinion comes up frequently:

If you want to adopt Go, you shouldn’t try to blindly translate patterns from other languages.

So, I wanted to learn how to write idiomatic code in Go and understand the reasons for the design decisions. I started my journey with book “Learning Go” written by Jon Bodner:

Learning Go

The book is well written, shows many examples and explains idiomatic Go design patterns. The book is for Go version 1.15 with a chapter about generics introduced in version 1.18. The current Go version is 1.19 as of this writing, but I didn’t find any groundbreaking new features in the latest releases.

The most fascinating part of the book for me, was chapter 10 “Concurrency in Go”. Concurrency model based on Communicating sequential processes paper from 1978. If you want to see how Go implements (more or less) this concurrency model, watch the session from Gopher conference presented by Kavya Joshi.

After this short video I had more unanswered questions than before, and I reached for another book: “Concurrency in Go” written by Katherine Cox-Buday 😀

Concurrency in Go

Finally, I started writing extensive summary of Go language, what I really like, what I don’t like and where I haven’t formed an opinion yet. After a week or so, I figured out that “my summary” has already been written by Sylvain Valez in the article Go: the Good, the Bad and the Ugly. The article covers all my personal notes taken during the books’ lecture and more. And I fully agree with Sylvian, really no single point for dispute.

My final, personal verdict about Go language is …

I don’t buy it. I can’t accept language with mutable basic data structures and lack of support for functional programming paradigm. Not in 2022.

Did I waste my time learning Go? Definitely not, and I would recommend learning Go if you are a Java, Scala, Python or JavaScript programmer. Even if you are using more sophisticated language on daily basis, learning Go gives a lesson, that developing “too smart” code doesn’t make you better software engineer 😜

Updated:

Comments

You May Also Enjoy

Test Driven Development for Data Engineers

26 minute read

Test Driven Development (TDD) is a well established practice in a software engineering community. It helps to guarantee that code is reliable and error-free by requiring developers to write tests before writing the actual code, and promotes better code design and modularity for easier maintenance and extension. Para...

Unified batch and streaming

18 minute read

Unified batch and streaming processing is a data architecture that seamlessly combines both batch and real-time data processing. It enables organizations to gain real-time insights from their data while maintaining the ability to process large volumes of historical data. In the past organizations often dealt with ba...

Back to a senior engineer

7 minute read

I started my professional software engineer career around the year 2000. For the next 14 years I was in an individual contributor role. When I joined Allegro in 2014 I had a choice: be a senior software engineer or become a team leader. I wanted to try something new and I started working as a team leader. After 9 ye...