Decompiled programs are full of approximations and guesses, and generally can't be recompiled without manual tweaking of the source code.

For example, "mov eax, 0x0040137C"

Is is this an address or a numeric constant?

Should it be translated to:

1) var = 4199292;

2) var = &SomeGlobalVariable;

If you're lucky you might get a non-ambiguous answer from the relocation table embedded in your executable.

So you're probably better off writing a new backend for the Go compiler (a backend generating machine code, or C code).

The resulting program will have, by far, a lot less dangerous approximations.

I can see the benefits, but I doubt it would be that simple. The Go code you decompiled would depend on a Go runtime. That specific Go runtime would then have dependencies on OS libraries. So for example, when you open a file in Go, I'd imagine that this functionality is built on top of the file handling functionality of Windows/OSX/Linux. You could work around these dependencies, but it's probably less hassle to port the Go runtime to the new OS.

Doesn't the Go runtime get linked in and would just get decompiled? It would generate a huge blob of C but the idea is just to port.

Not everything that the program needs to run is included in the binary.

Let's use a more concrete example. Let's say we write a Go program that copies a file. On Windows, this might use an API call like CopyFile:

https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

If you decompile the compiled Go program into C, it'd still have the references to API calls like this. These APIs would have to be implemented on the new OS for the decompiled program to work without modification.