I am fascinated. Maybe that should be enough, but I guess I have to write a bit more here, because we are not in twitter.

I spent a few days to get know Go language, and now I am more than satisfied. I mean, all the project ideas which are floating in my head should be written in Go.

First of all, I have rewritten Mambo-collector to go (https://github.com/banyek/mambo) because I have faced some serious errors when I used it on CentOS 7 – I blame systemd -: If the process was running as root then after a few days of data collecting, killing that process was lead to restart the entire system, which is not a bug, it is a catastrophe. I tried to debug it several ways, but I am not sure where the problem is, it could be at the ‘loghandler’ redirection, or any other place in python-daemon, or it is simply there is a buffer inside which overflows – I don’t really care, because mambo was just a proof of concept – what I used in production. I decided to abandon the project, and rewrite it in a language, what is designed for what mambo is: a system process with high amount of parallel data processing. In the original version I spawned an os thread for every query which will run (and we know that there is no real multithreading in python because of the global interpreter lock, at the end, building a multithreaded application in python is just an illusion. It is good for helping you to imagine what will happen inside your the computer, but you cannot expect real multithreading. It wasn’t a real problem, because I only ran/run a few queries with mambo – replication lag, all processes inside mysql, active processes inside mysql – but if there would be a need to increase the number of queries that could lead to trouble. And it’s needless to say, if you have a lot of time.sleep in your program, that is not the most wise use of your CPU resources: if a CPU is sleeping, then you waste resources.I have enough resources to let waste a bit, but it always disturbed me.

At the end I decided to rewrite mambo in go.

I won’t introduce Go, I recommend instead to read The Little Go Book, go through the Go tour, and at the end check the Go by Example page.

But here are some bullet points which I liked most in this project:

  • The command line parsing is elegant, quick and easy with the flag module
  • The goroutines and channels are not only elegant, but they just solve all the multiprocessing problems you will encounter. You can start a parallel function saying go func() and you can just simply forget it. If you define channels, then you can just direct the output of these routines into, or read data from there. And you have not to worry about mutex locks. Oh, and you don’t have to worry about not used threads, because goroutines are not equals os threads. Let the scheduler decide what is the optimal for you. You can just fire and forget, saying I want to parallelise this function.
  • I liked the use of pointers. It is good that reading the code I can decide if I access the data itself or just a copy of that. (Yeah, I also love coding in perl because of the referrences, and using pointers in go is closer to perl references than C references)
  • The code is clean and short. No superfluous lexical elements.
  • The go fmt tool is just marvellous. No more linting, no more fighting about tabs/spaces, no trailing whitespaces, just run go fmt against your code, and it will edit it to the standard one.
  • go get is an easy way to install packages
  • it enforces you to use clean code, it won’t compile if there is an unused variable or import
  • The documentation is nice

Well there are some stuff which I didn’t loved so far:

  • The go get is easy to install packages, but it is not clear to me what to do with them. I mean, should I include them to my project, or add to the .gitignore file and let the build script fetch them (I do this, but I am not sure if this is the best way)
  • Well, go get fetches the actual version, so I don’t know what to do if you want to use an older one. The little go book mentions goop and godep, but I have to check them out.
  • I didn’t liked that slices are pointers, but you refer to them as single variables. I understand the purpose of this, but it just makes it a bit clumsy.

Anyways, my first project in go is almost done, and it was really a good experience by far. I guess I’ll spend more time around go projects and get more experience.