A freelance Go developer for the paths where latency costs money.

At a fixed price or by time spent, to suit the project and the model you prefer; I name the range in the first call, once scope and timeframe are clear. For the most common entry point there is a package with a price: the bottleneck measurement of your application at a fixed price of 1,900 euros, with a result within a week. It is credited if you commission the implementation afterwards.

Yes. The language is called Go; "Golang" established itself as a search term because "Go" on its own is hard to search for. Both mean the same language, and this page answers both searches.

Almost certainly not, and I say that although I would earn money from it. A complete rewrite loses the unwritten rules of the existing system and chases a moving target for years. The reliable path is to extract the path with the load problem and put it alongside as a Go service. The rest stays until there is a reason of its own for the next step.

That is the normal case, not the exception. The Go service takes over the path that needs load or latency and is connected via gRPC or HTTP, with the same database or a clear data boundary. I have more than 20 years of PHP experience and know both sides of that connection; what it looks like in practice is in my article on Go in a PHP world.

By measuring instead of believing. Before the implementation there is a bottleneck measurement: where is the time actually lost, in the code, the database, the network? If the bottleneck does not sit in the path itself, a faster language changes nothing, and then you get exactly that finding instead of a service that improves nothing.

Yes. Go services get left behind without their author too, usually with little documentation and a deployment only one person knew. The process is the same as with any takeover: understand and secure first, change second. Tests, metrics and runbooks are created along the way, so the dependency on one person does not merely change its name.

That is not a question of faith but of cut. A single, clearly bounded Go service alongside an existing system is often the whole answer; a web of twenty micro-services almost never is. I cut along data boundaries and rate of change, not along architecture fashions, and I justify the cut in writing.

I do, and systematically. I work spec-driven: requirements are written down precisely before code is produced, and every change passes tests, the race detector and review before it reaches your repository. The tools bring speed; the quality gates are the same as for handwritten code. I am responsible for the result, not the tool.