After working with Go language a little bit in a project, I dove into studying it for a few days. Here are my impressions.

Stark minimalism

My central impression of Go is a kind of stark minimalism in language design. The language is small, with relatively small amount of features; after going over some online tutorials and references, I feel I already understand it to a large degree. Go adheres to “There should be one-- and preferably only one --obvious way to do it.” part of the Zen of Python far better than Python does. Go also shares the “batteries included” philosophy, which is nice.

Features to appreciate

I like the concurrency model of Go a lot, it’s different than Elixir’s, but just as convenient. It’s not quite as powerful IMHO, given the features of Erlang VM and OTP, but probably easier to understand as a newcomer. For concurrent things, it’s definitely more user-friendly than, say, JS or Python. I also like the separation of data and behavior, automatic formatting via gofmt, and the rather neat way to set public or private attributes via capitalization.

Go Design

What I’m more conflicted about is the side effects of the design goals of the language. Go is designed to be a language that you can make huge enterprise projects with, with programmers of varying styles and skill levels. You can bring in a programmer who doesn’t know Go, get them up to speed on the language relatively quickly (as long as they’ve worked with C/Algol style language before) and have them dive into an existing codebase, with a high change they can understand what’s going on. This is pure win from an organization’s perspective.

The Good Is the Bad

Go achieves this by including as few footguns as possible, or even footpeashooters; the language is restricted in features, and the features it has are designed to promote explicitness, readability, and least surprise from the perspective of a programmer who is already trained in a C-style language. This means no one-line ternary operations, or functional programming features like map/filter/reduce or list comprehensions, and for sure no macros or powerful metaprogramming features.

Go code will be more verbose than equivalent code written in Python or Elixir or Rust. This is by design; powerful language features give more ways for people to shoot themselves (or the ones maintaining the project and reading the code after them) in the foot. I feel I’ll be missing the power of other languages when working with Go, although I acknowledge the benefits from an organizational perspective (depending on the organization).

Here’s an article elaborating Go’s design goals and philosophy: https://talks.golang.org/2012/splash.article

Conclusion

Anyway, I do like Go, and look forward to working with it in the future. As the standard language of cloud infrastructure, knowing it will very likely be useful. If there’s something you’d like to add to - or correct - in this neophyte’s review of Go, please send me your comments jukka@montel.fi.

To hear more about Montel's know-how, please don’t hesitate to contact our head of Sales Mikko "Tuba" Tuominen +358 40 063 6636 tuba@montel.fi.

Montel Intergalactic Blog

Tips, views and stories from our software gurus, DevOpsmasterminds, and other experts

Go - a Neophyte’s Review

Let's talk!

Montel Intergalactic

Home

Development

DevOps

Who we are

Careers

Blog

Montel
Intergalactic Blog

Tips, views and stories from our software gurus, DevOps
masterminds, and other experts