Why We switched from Python To Go

There are many good reasons to switch from Python to Go, but that article misses them all.

When people say they like Go's static type system sometimes they are comparing it to something more verbose like Java.

Think about someone that knows Python and have to use Java, then they think that all static type languages are as a pain in the ass. So they begin disliking static type systems when they really just hate the Java's one.

And so the moment they are using Python and start playing with Go they find a static type system they kinda like because it's less verbose and without so much ceremony.

Oh why would I get an unusual exception, if I tried doing that _without even a try except block_ hust, I wonder ... must be because of the language itself and how it works.

> [static typing]

Why would you have started with Python, if you did not like dynamic typing? Also I doubt that static typing saves any time at all. It might also depend on what you are used to.

> [performance]

I am not sure what the application is for what Go is used in this case, so one cannot really talk about the necessity of speed in the authors use case.

However, the static typing example was a Django thing, so might be it is about some web app. Web apps are typically not the most performance needy things around.

Before bringing up the performance argument, one should check whether the performance of the language is the bottleneck or rather some I/O, like reading from disk, database or network (for which the appropriate libraries are responsible, like a database driver, which is likely to have similar performance across libraries).

If it is really about some calculation being done in the language itself, there are many high performance libraries available for Python, which are implemented in Fortran and C, so I doubt that in a proper setting using Go instead of Python and its libraries would have much of a lead in terms of performance. If you are doing massive matrix operations in the language itself, then it is sort of your own fault. Python is a language, which lives from its rich ecosystem. If you don't use it and look out for stuff, which could help you, then yeah ...

> [built-in http json ...]

Many of those Python has as well and since when is built-in automatically better than an available library, if the source code of the library is properly checked, before going to the official repositories? From a minimalistic point of view, one could even argue, that it should not be part of the language and that one can "customize" ones setup depending on the task at hand. If looking at the time needed for setup, it is only once a creation of some virtual environment (virtualenv, anaconda, whatever else there is) and you are done.

What happens, when there is an update to Go or a series of updates, which add a new feature, for example like Python's `async` and you want that in your application? You'd need to update your language compiler. But what if some of the so nicely built-in libraries changed as well and is now incompatible with what you wrote before? Maybe some function had a bad name and got renamed. Bam! You cannot update your language compiler/interpreter without breaking things. And why is that? Because the built-in library is not decoupled from the language itself. If it was not built-in, you could have it tell you, that it is only compatible with some version of Go. That's how it works with Python's libraries in anaconda environments and it is all automatically taken care of for you.

> [IDE]

Meh, Python got those too. I am still using Emacs amd Vim instead of an IDE. It didn't make me any less productive.

The syntax and ecosystem weren't really critical factors, but writing concurrent code is a lot more fun in Go.