I wrote the blog post, thanks Serge for the great library! I considered the self-contained app without the web server method, but I've already done the images before and I'm way more comfortable with Go web programming (I wrote that book too).
You're probably right, I'm just mucking around with various things, didn't really thought too much about optimizing the code. The frame rate on the terminal is basically as fast as iTerm2 can display the image, I can't really control it (except maybe make it slower). It looks rather fast on the GIF because I cut down the number of frames in the GIF, but the actual game runs more reasonably.
Not really. I started with Ruby, Python and PHP but it's very much possible with compiled languages like C/C++. There's a whole bunch of client software that allows you communicate with RabbitMQ - https://www.rabbitmq.com/devtools.html
Thanks for the suggestion, it's a good one. A few cases a message queue can be advantageous -- (1) persistence (2) a few responders can work on the same request in parallel (3) adding/removing responders dynamically according to the load.
These are not common/generic use cases but would be useful under particular circumstances.
* I could be wrong with (3) -- I'm not very experienced in reverse proxies.
The implementation today is as a task queue which removes the request from the queue once a responder acknowledges, but it could be a pub-sub model, where a number of independent responders can work on the same message in parallel, and only 1 responder need to return a response. In this case, persisting in the queue is useful.
An alternative is to chain the responders where one responder can leave a message in the queue for another responder, and the final responder returns the response.
Polyglot is still experimental though, and the current implementation is a prototype.