As a programming language enjoyer, I finally tried out Go.

Takeaways

1. People say Go is simple. I agree. There aren’t many language features, and that might be a good thing. My project needed a hashset, and I was quite annoyed that there was no hashset implmenetation in the standard library that everyone seems to praise. I used a dependency from Hashicorp to get around this. I later read from a stackoverflow post that people would just use a map with the value being set to true. I thought this was dumb, but I decided to try it out and the ergonomics weren’t terrible. I could live with it. If only Go included a built in map or filter function, sigh.

2. Go and Neovim work great together. My current setup is just the kickstart.nvim from TJ with a few changes. Even with minimal configuration, I feel that I have everything I wanted from VS Code. I do miss the refactoring capabilities of Intellij’s products, so I did later install GoLand. I am sure there is a way to configure Neovim, but I haven’t taken the time to figure it out.

3. I like Go’s error handeling. The verbosity forces you to think about errors. I also really like the multiple return values that Go suports. I find this suits my brain better than the optional types in Java. In Java, I felt I was being just as verbose or having to use the odd feeling streams API to deal with errors. It was either a skill issue or Java being Java. The only thing that is not 100% clear is when to just return the error, when to make a new error, or when to panic. With the way I was writing my first project with many functions, errors became a little hard to keep track of. I’ll figure it out in time.

4. The built in way to write tests is neat. Too bad I don’t write tests. Just kidding, I wrote a few tests at the beginning, but then refactored and never bothered to update the tests. They are still failing. Oh well.

5. The libraries available for Go have met my needs. My CLI application needed to process excel files, so I used qax-os/excelize. I used urfave/cli to meet my CLI dependency. It works great and the documentation was clear. I might investigate Cobra the next time I have to write a CLI app. Lastly, these were my only 2 dependencies which is neat.

6. No OOP. To be honest, this takeaway is a bit superficial. No one forces you to use OOP features when coding in Java or C#. But it is still there. You feel inclined to use it. The last version of this CLI app was a poorly written script made with Dotnet. I still had a little bit of OOP boilerplate to write and think about. There’s probably a way around it in C#. But in Go, I just start writing functions kind of like how I would write Python.

7. Go makes a good scripting language. I can imagine myself doing many scripting tasks with Go. It’s like Python with a slightly worse syntax (and a lot less syntactic sugar) but also includes the benefits of static typing. I won’t try to argue any performance improvements as I haven’t done any benchmarks. It just feels that Go would be faster based on compiled vs. interpreted languages.

8. Go having cross-platform support is one of the best features. It’s why I picked this language for this project. No more thinking about if users have the right JVM or CLR. I do have some concerns (and potential bugs) about hardcoded paths between different OS’s, but yeah, hard coded paths are just bad in general. I also appreciate small executable sizes. A hello world console app in dotnet with the CLR bundled in was around 8 times as large as my completed Go project!

9. Channels are great. They were tricky to understand at first, but once I played around with them it clicked enough for me to be parelleize my project. I experienced a near 5x runtime improvement by using all 16 threads on my computer. Interestingly, making my program execute with go routines made me improve the quality of code. It forced me to single out the parallel section which ended up making a great function. I still struggle with deciding when I want to separate code out into separate functions. Especially on these small projects where I am the sole developer. Currently, I have decided to not separate code unless I repeat it 3 times. It still up to my discretion when to separate out, but I find that having all the code in the same locality makes it very clear to reason about, ie. no need to think about what the function name is telling me.

10. I wish Go had better string interpolation. It makes everything stirng output and print deubgging so much better.

11. The Go compiler is too strict when it comes to unused variables. I found myself commenting out code to debug, but then being able to compile because a variable is unused. It is not exactly great to just comment out code, run it, and see if it crashes, but I still want to be able to do this when the cause of crashing is not clear. A compiler warning would be much better.

I plan to keep learning Go. It feels suited to the solo developer. I don’t have to worry about SOLID, coding in a way that others can read (Go is readable and really has only 1 way to do things), and having many dependencies. I plan to do more with parelleism and go routines, create a CRUD web API, and perhaps even code a game server with a frontend.