The Parts of Go That I Like
Hey there. It's been almost a year since I've picked up Go language as the main programming language for my day to day work and I think it is time to summarize my experience with it. Since the sole purpose of this summary is to collect interesting ideas regarding programming language and ecosystem design, I will only focus on the parts that I find good and valuable. Other people already did a good job spotting numerous Go shortcomings, so I don't think I can bring anything new to the topic.
Without further ado, here are these parts:
Unified code style
Composition, not inheritance
Rich standard library
Now let's look at each of them more closely.
Unified Code Style
As a person who doesn't care about having a particular code style in the
project, rather some style that is used consistently, I can't say how much I'm
satisfied with the
gofmt tool. It helps teams to avoid lots of poorly reasoned
debates and do their job already. I think that every programming language that
is supposed to be used in collaborative development should come with a tool like
Composition, not Inheritance
Though I don't think that traditional inheritance-based OOP is worthless, I believe that in most cases composition does a better job than inheritance because it is much easier to reason about. There are fewer things to consider when designing an entity that is supposed to be used exclusively via composition: you need to design only its private and public interfaces. When it comes to inheritance, you also need to consider your "protected" interface; that is an interface exposed to the descendants of your entity. Then there is overriding that I believe also complicates understanding of what happens in the object hierarchy. To sum up, composition might be less expressive than inheritance, but at the same time it is much easier to comprehend and just enough to do the job fine in most cases.
Rich Standard Library
This is a controversial trait, because there are people believing that a
programming language should have as minimal stdlib as possible, and I think it's
a valid option in some cases, e.g. Rust chose this approach because it will
allow using Rust in embedded environments relatively easy. For a more
general-purposed programming language, I think it is beneficial to have a rich
and well-designed standard library. I remember how cool it was to use only
Python to get things done, though Python's stdlib is not what I'd describe as
httplib, ugh). Well, Go does a much better job here; you can
say that by looking at the number of third-party implementations of JSON parsers
and HTTP clients for it.
Last, but not least is how Go documents things. I'm talking not only about the code documentation, but also about numerous tutorials and blog posts, as well as tools such as Go playground. They do a really good job of educating people about best practices and right ways of doing things in Go.
Is that it?
Pretty much, yeah. Though Go is far from being my favorite programming language, I think it does a really good job on the things I've mentioned in the post. I might have missed something; I'd be glad if you could drop me a line and mention what do you consider to be a good part of Go and why. Cheers!