#1 Performance
#2 Performance (to make the list longer I guess?)
#5 Fast compile time... which is an advantage over Python how exactly?
#7 Strong ecosystem... which brings us to disadvantage #1 - lack of frameworks (?)
Also re #3 and #6 - I found learning Go to be relatively painless, coming from a Python background. It was helpful to have much more experienced teammates and to have some opinionated pre-existing infra (e.g. tests, lint, deploy, general app architecture). The lack of frameworks is good/bad -- more decisions to make (though the standard Go libraries seem to almost always be good enough) but if everyone is mostly using some combination of modular libraries, it means that problems are easier to debug and search for on StackOverflow, versus needing to add if the error is in Flask or Django or some other bespoke framework.
Compiled code can have fewer runtime errors, that's a big win. I read this as golang is better than python because it's compiled and golang is better than Java and C++ because the compiler is fast.
And as far as type systems go, Go is one of the worst in mainstream usage.
Heck, you can even use HKTs in Python if you are willing to install a plugin/library.
Golang's typing system is fairly half-done.
I'd also count Python with MyPy, but having a mostly untyped ecosystem means you can't take much advantage of it.
All things that Java, Go, C# and others just can't be the best at because of the overhead or GC.
Am I missing something? Is there some way in which numpy is superior to, say, Linpack (other than not having to use Fortran to call it)?
Is there anything unique about Python that enables this approach? Couldn't Go, say, do the same thing? Or C++?
Network effect. I don't think anything stops most languages from doing most of what NumPy does (although IMHO even post-generics Go is actually a bad choice), but you have to compete with the existing NumPy. Competitors exist, but, well, the fact you don't know about them and haven't heard of them kinda makes my point.
In fact in my personal opinion Python is an unfortunate choice for NumPy. NumPy is so big it is basically its own thing, and data scientists could have learned to half-program in almost any modern language. (Rust might have given them fits, and C++ would cause some issues, but most languages would have worked for them.) Unfortunately, they settled on a language with weak types, which makes the documentation really annoying to use because it's very hard to tell what will work with what. (I've been dipping into NumPy and pandas over the past few weeks, the docs are infuriating... it's like, they make it obvious there's something that will do what you want but it's quite difficult to backengineer what that "something" is if you don't already know, because nothing has types anywhere. I can already tell you just sort of "get used to it", but it would be easier and faster if there was some type indications somewhere.) And perhaps even worse, as you scale up the size of what you're doing in Python, anything that isn't accelerated becomes more and more mindbogglingly-slow, because when you're in Python you are in a terribly slow single-CPU language banged together with the highest-performance multi-core if not GPU-based code in the world, and the gap between those two things just keeps opening larger and larger. Knowing when you're in slow land and when you're in fast land takes expert-level knowledge and at times source code reading. I'm glad I'm just visiting, I think living there would drive me insane.
C++ could give you equal or better performance, but it's not anywhere near as friendly to beginners as Python. Plus, the value of REPL-based programming for prototypes and experimentation is hard to overstate.
https://www.youtube.com/watch?v=LoypcRqn-xA
Plenty of other frameworks which you have a specific framework is lacking in the Go ecosystem?
I think this would probably be more why they switched to Go, rather than why they switched away from Python.
Alternately, how fast are Python linters? It might be faster to compile Go than to run their linter (or whatever).
It is only a disadvantage if you want to have a framework.
I prefer frameworks the same way I prefer code linters and formatters. Which is to say they are annoying, but far less annoying than working with a team that spends obscene amounts of time discussing/rewriting code based on opinions. Frameworks come with their own opinions and can help remove a lot of those barriers.