My First Experience with Go
I have wanted to learn and use Go for a long time. I got a chance at work to start using it to solve some problems. It has been a great experience so far.
The reasons I like Go from afar are: static binary, simpler concurrency, cross compiling, rising popularity, simple and familiar syntax, and better performance than Python. I found all of this to be true.
I really, really like the idea of building, shipping, and using a static binary. When I write in Python, I always have to be mindful of the platform where my code will end up. I have to think of the Python version installed, whether the user will have enough privileges on the system to install dependencies, and writing install instructions for someone who is not familiar with Python. None of that applies to Go because I build a single binary that the user can plop anywhere on the file system and run it. This ties into the cross compiling abilities of Go. I can build binaries for multiple operating systems and architectures from a single place. That's unprecendented power for someone like me.
With version 1.11 I got the experience of putting my foo.go file anywhere in the file system and running it like a script. It removes the pain of GOPATH. Now I can treat my Go code like Python during development. It's the best of both worlds.
Go's syntax is very familiar and simple. I haven't learned all the features yet but I can still get work done. The common complaints of error handling did not bother me. It was a nice change from not thinking about errors to being cognizant of less happy paths. It slows down the thought train but not enough to be bothersome.
My biggest hurdle so far has been trying to understand the documentation, both for the standard packages and libraries others have written. There aren't enough examples on how to use the function or type. I stumbled a lot trying to figure out how to make the parameter look like or be what the function expected or how to convert the returned value into a type that would be more useful further in the code.
I am not a big fan of static types. I love the Python type system because it lets me solve a problem instead of thinking of the shape of the box the problem looks like and forming the solution to fit in it. For example, I can create a list of items that don't all have to be the same type. I can't do that in Go. I have to spend more time thinking of what the type of something is rather than completing my original task. I have enough experience with Python that I don't have that problem there. Maybe it is my inexperience with Go but it definitely is a problem: I am very slow in implementing things I could implement much faster with Python. When deadlines are looming that becomes a huge factor.
I also found the library ecosystem of Go to still be far behind Python's. There are a ton of great libraries, don't get me wrong, but the ones I need are either not present or too low level. For example, I wanted to write a simple script to run commands over ssh or transfer files to other hosts. With Python I have the great library, Fabric, available. It just lets me do these things without needing to wade waist deep in ssh. There's no such alternative in Go yet. So I had to learn more about ssh internals than I ever cared to do and gave up in the middle.
My final take away is that Go is a great language. I want to use it to augment, if not replace, Python at work and in my hobby projects. Go is very enjoyable to use. It doesn't yet have the libraries I need to get things done quickly. Its documentation also needs to have lots more examples on how things work together. I will continue to write more things in Go but maybe not the things that need to get done asap.