After using a few very good applications written in Go (Syncthing, Docker and Hugo are some examples) I wanted to get to learn a bit more about the language.
I'm very interested in programming languages theory and how it could give developers the tools they need to write software in the best possible way and with as many guarantees as possible on the correctness of the resulting applications.
To get an idea of where programming languages theory is headed have a look at the post Graydon Hoare (the creator of Rust and now one of Swift's developers) published discussing possible new research directions for programming languages.
I obviously wasn't expecting Go to address any of these issues but I find it very interesting that its designers deliberately ignored lots of what I would consider basics features in the name of simplicity.
The lack of generics is often mentioned in discussions regarding Go.
I would have liked Go to have algebraic data types and immutability by default. I would gladly give nil away to get these features.
On the positive side, Go has good libraries, good tooling, a common style and a syntax that is extremely easy to pick up. It's fast enough and it has good support for concurrency via goroutines. It also produces executables that are very easy to deploy anywhere.
Given this description, it seems to me that Go is an evolution of C and Python and I decided to give it a try rewriting a project originally written in Python I am working on.
That project is very simple, small and self contained. It interacts with Twitter (a good library is a huge plus), and it analyzes my interactions with the people I follow.
The goal is to find out if I'm following people I am not interacting with much.
I somehow ended up following too many people and I needed to find a way to bring my following to a more manageable number.
That is admittedly something too simple to draw conclusions, but I think it was still good enough to get a feeling of the language and I had a good impression.
Picking up the language has been very easy, the library I used is good. With respect to Python I have a type system, albeit limited, and I get an executable I can easily deploy with no additional dependencies.
Given this experience I believe I'll consider Go again for projects of a similar size and scope or for simple command line applications.
For that use case, I believe it's a much better fit than Python while it's simplicity could make me be more productive than if I were using other languages.
Originally posted on mariosangiorgio.github.io
Latest comments (5)
Until go decides to support generics I will not even consider it as an option. To me it seems like nothing more than a bike-shedding type of language that does not solve any real problem. Why bother? I just can't find the motivation of putting even a sliver of effort to learn the language.
Thanks for the comment. How is their libraries ecosystem?
Hi Mario, nice analysis, it's a very interesting language indeed!
Could it be that the reason why they decided to part with generics is, other than simplicity, the fact they had to appeal to the large audience of C developers? In its current form it seems like it can be picked up in an afternoon by an experienced C developer, maybe a little more from someone used to dynamic higher level languages.
One thing I do not like about Go (I have very, very, little experience to be honest) is the way they do error checking, all those
if err != nilat some point look like a design flaw, even if they make the code super fast. What do you think?Also the package manager seems very primitive if you compare it to things like pip, yarn or bundler.
I'm not sure if generics have been left out to appeal to C developers. At least, in the FAQ they explicitly say that they want to keep the language and the runtime simple golang.org/doc/faq#generics
Regarding error checking, I think that having algebraic data types and pattern matching would have been cleaner and safer. Code can still be super fast with them (have a look at Rust).
I haven't had a chance to use the package manager much so I don't have a clear opinion. If I remember correctly, I read that some of the design decision were rooted in Google using a monorepo, which is a different scenario than what you would normally be in.
I think some work is being done on the package management system so this will likely improve in the future
Thanks Mario, I almost forgot about pattern matching for error handling. That would be very nice indeed.
I've read this article and it makes very interesting points: yager.io/programming/go.html