Go for Python Programmers

By Trey Tacon

For the past several years, Python was my go-to language for most projects. I appreciated its (list of features, benefits) and still do.

But once I started programming in Go, I never looked back.

If Python and C got it on…

At first glance I didn’t understand what all the hype was about. Sure, Go was created by some of the best programming minds out there and was already being adopted by several  fairly large companies.  But I didn’t see the point in using it over my beloved, loosely-typed and easy-to-develop Python.

Then I dove in the deep end and had a change of heart:

Go is the love child of C and Python…it has Python’s good looks and pleasant demeanor, and C’s confidence and athletic ability. In other words: Go is nearly perfect.

Go for Python Programmers

After spending a month programming solely in Go, I found it literally impossible to do some of the same things in Python.

And while I was a little annoyed at Go’s concurrency as an actual semantic construct you could express in the language (instead of some mammoth library), it was something I eventually fell in love with. It’s just a little weird to start working with a program with that sort of power cooked right into the language itself when you’re not ready for it.

No Exceptions? No Problem.

Coming from a strong Java and Python background I’ve always relied heavily on exceptions. So I found it a bit odd at first, to not have exceptions in Go. But after writing Go for a while, I came to question the need for them. If anything, exceptions merely give you the ability to smash back up the execution stack, ignoring everything else in functions which were on the call stack until we find somewhere (or don’t, uh oh) where that exception is handled.

At first glance this seems ideal, we try some functionality which may or may not be able to complete, and let it do its work until any issue bubbles back up to us. The issue with this is that if a programmer or library writer wants to clean up any resources at one step, but also wants to bubble this same exception back upwards, they now have to catch this exception themselves, do any resource cleanup they need to, and then rethrow the exception.

This is (a) messy, (b) extremely verbose and (c) no different than errors in Go, except that there’s no throwing/catching/etc. We simply return a possible error along with whatever other return values we want. Some people may say that this leads to redundant looking code, and yes it is, but so is proper exception handling in Python – the only difference is it’s more verbose in Python.

Go Play!

I’ll save all you Python programmers the trouble of discovering that there’s no single REPL for Go — there are many.  However, the Go REPLS have been largely produced by its open source community so I cannot vouch for their usefulness.

However, Go does have an officially supported solution: the Go Playground. The Go playground is amazing because you can toss up any kind of test program and share it with others (similar to a plunkr for frontend inclined individuals). Or read more for yourself about the Go Playground in this blog post.

In summary, Python and Go are both great languages that solve different challenges. But, in my experience, once a team or programmer has made the transition to Go they don’t normally turn back.