You have a lot of technical debts in your concurrency code and don't think you have the skills to solve them internally while Go would let you do it.

You have data about your deployment and weighted security updates easiness against self enclosed binaries and the later is more appealing.

You evaluated the cost of a rewrite in the current used language vs the new one, including training and documentation and it was in favor of Go.

You have embarrassingly parallel operations the market / your resources forces you to optimize and the serialization cost of data makes it impractical with multiprocessing.

You want a sweat spot between verbosity, high/low level, productivity and performances and don't mind having something average in every of those aspects as long as it's balanced.

You are aware of the cons of Go (very heavy error handling, skinny stdlib, youth of the ecosystem, etc) and it's still worth it.

You made a prototype of a basic task you had in the previous tech, with the last version of the previous tech and Go and the ratio "cost / result" is clearly in favor of Go.

You have experts in Go in your team and their talent would largely compensate the lost of the talent in previous tech.

You deeply checked Java, Erlang, C#, Haskell, Rust and JS as alternatives and your team agreed Go would still be better.

You checked solutions to your problem (e.g: for python, you tried crossbar before being sure you can't do your microservices properly) and damn, Go still solves them better.

You know how much RAM your service can afford, and spawning goroutines likes it's going out of style will be the proper ratio of easiness vs cost.

Basically all this posts says is "x is good so it's cool we have it". Good reasons to switch are never black and white, they are justified by experience and data, in a specific context, relatively to pros and cons of other solutions.

Anything else is just geeks being geeks and wanting cyber poneys. I understand that, I do it all the time. Loving your job and trying new stuff is a perfectly reasonable motive in my book

But I'm not going to write a blog post about it pretending I had technical reasons while I did clearly zero measurements and I am just quoting what other people say about Go.

The blog post sounds more like they had lunch and they said "dude, we should totally rewrite that in Go" and went for it. Then they measure a newly created service against legacy code and say it's better. Well, guess what, if you make a successful rewrite of anything with the same people, it will be better because you had the experience of the previous one.

The clue here is when they said they had less code in Go than in Python. This is clearly a red flag.

Plus if you had only 35% gain of perf from your Go system, something is wrong. With pypy only I can gain up to 800% of speed on my 2.7 system without changing a line of code. In 3.6 with libuv and asyncio you can also get a huge gain on IO operations.

Done properly, you should have way more gains from a Go rewrite. Or your problem didn't need Go.

No research has been done here.