Testing can be more difficult in some cases, if you haven't carefully structured your code. In python you can always monkey patch whatever outside dependencies you have, whereas in Go, you can't do that without structuring your code to allow it. Careful use of interfaces and dependency injection can let you do it, but if you don't know to use that style, you can get big blocks of code that become hard to test because they expect the whole operating environment to exist, which may be hard to do during testing.
If you want to write code in a Domain Specific Language (even if that domain is "math"), it's nearly impossible in Go. You can't do operator overloading or all the really crazy hacking on the functionality of basic parts of the language to make it work in fundamentally different ways (the way you can with numpy etc). Go will always look like types, functions, and methods.
Right now, Go has no user-defined generics.. this is actually not a problem for many projects, but if you happen to need a lot of specialized containers for different types (like red black trees, graphs, etc), then it can be a barrier. There are ways around it, probably the best way is just code generation to duplicate the container code per type that you need. The other option is just using interface{}, which is basically void* or "Object" for Go, and casting in and out of it... but that can be slow.
There's probably some stuff I'm missing, but those are the major points that I can think of.
My guess is that if you've written code that's hard to test in Go, it's going to be hard to write good, non-brittle tests in Python. It's not so much that you need to write code amenable to dependency-injection to write good tests, you just need to write modular code.
As a fan of DSLs, I actually do appreciate how easy it is to understand any Go that anyone has written, since there aren't any cutesy DSL tricks anywhere. So, yeah, it's hard/impossible to do DSLs, but that might not be a Bad Thing.
Generics is a (frequently discussed) downside. It's definitely a tradeoff. For every container type we had, we had to make a copy of it or a typesafe wrapper around it for every possible instantiation of the container with different types. If you're used to coding by making flexible containers and so on, that's definitely much more brittle and challenging in Go. Go peeps will tell you that's part of a tradeoff they're willing to take.
If you want to write code in a Domain Specific Language (even if that domain is "math"), it's nearly impossible in Go. You can't do operator overloading or all the really crazy hacking on the functionality of basic parts of the language to make it work in fundamentally different ways (the way you can with numpy etc). Go will always look like types, functions, and methods.
Right now, Go has no user-defined generics.. this is actually not a problem for many projects, but if you happen to need a lot of specialized containers for different types (like red black trees, graphs, etc), then it can be a barrier. There are ways around it, probably the best way is just code generation to duplicate the container code per type that you need. The other option is just using interface{}, which is basically void* or "Object" for Go, and casting in and out of it... but that can be slow.
There's probably some stuff I'm missing, but those are the major points that I can think of.