Hmm, why exclude #4: Concurrency and Channels? Concurrency in Python is a nightmare; in fact, doing anything more complex than embarassingly parallel computation in Python is a nightmare. Goroutines are excellent for lots of application logic, especially if your operations are being blocked (e.g. querying a database and waiting for the response). I'll admit the difference is less large if you are doing big data computation / ETL where tasks are long-lived and you can eat the overhead, but the post was specifically for an application's web server.

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.

> #5 Fast compile time... which is an advantage over Python how exactly?

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.

The advantage then is "the type system", not "fast compile time".

And as far as type systems go, Go is one of the worst in mainstream usage.

Just curious, which languages have better type systems?

TypeScript, Kotlin, Scala, Haskell, Rust, Swift, modern Java, C#, F#, OCaml, Reason, Elm, PureScript,... it's a long list.

I'd also count Python with MyPy, but having a mostly untyped ecosystem means you can't take much advantage of it.

It's easier to list which ones don't at this point. The Go team ignored the last 50 years of improvements in type systems.

All of them? Minus the dynamic/weaks, such as original javascript.

Rust, Haskell, OCaml, and many others.

Golang's typing system is fairly half-done.

But still better than Python's.

Despite its warts, Python's type system is at least comparable to Go, and better in several areas. The type inference works really well much of the time without any assistance, you can use tools like pyre to generate types for untyped code, as well as tools for discerning types through running the application.

Heck, you can even use HKTs in Python if you are willing to install a plugin/library.

https://returns.readthedocs.io/en/latest/pages/hkt.html

I can understand the point - compiling will do the same checks a type hint checker such as MyPy will do and it's a bit faster. I have that in my pre-push hooks, but a lot of people isn't used to the 90's when a compile could take minutes and demand a far less relaxed development pace.

I have a hard time believing Go compiler being faster than Java’s. Like, none of them do barely any optimizations, but Go still has to do a bit more.

Javac is extremely fast. It doesn’t have to do any optimizations.

#7 given Go can't compare to Python on ecosystem breadth and depth, its a curious choice of "reason to switch"

It's been a while since I wanted something in Go that wasn't available, other than the obvious big-ticket items like NumPy which are ecosystems unto themselves. (Or, to put it another way, yeah, Go doesn't have NumPy, but neither does anybody else other than Python at this point.) YMMV, of course, but it's certainly not a routine occurrence.

The other packages I've missed are all Rust or C packages that manage to create absurdly compact or performant versions of low level structures and blocks like tries, probabilistic filters, encryption primitives, or custom binary storage solutions.

All things that Java, Go, C# and others just can't be the best at because of the overhead or GC.

There are definitely data structures that are a massive pain in the ass (if not impossible) without a GC of some kind.

If I understand correctly, numpy at least originally was a wrapper around some Fortran libraries. So you could get the same functionality and performance in Fortran.

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++?

"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.

Python has a GC based around reference counting, which is vastly easier to integrate with native code than languages with heavier runtimes such as Go, Java, C#.

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.

C++ has had repls forever (first the terrible hack of cint, now cling).

I took it to be a reason they chose Go over some other alternative to Python.

the choice was a personal preference, and justified after the fact. This kind of justification happens way too often in a lot of shops, esp. if it is ran by someone with strong opinions and preferences.

No runtime requirement, single exe, and cross compiling were big one for me as well

Sure I am reading a bit into this but the reason they moved away from Python was performance. So ditching Python as a given, here are the reasons to select Go instead of something else.

I'm surprised they didn't mention #1 implies a cost benefit, or maybe they don't use it at scale in certain areas that it matters. I worked with one company that switched from Python to Go. They went from twenty-one instances of their load-balanced API servers to seven, saving a few thousand dollars every month.

This is my favorite advantage of Go. It does the work faster with fewer resources. I know there are a lot of aesthetic complaints about the language but I don't care.

There is a new framework, still infancy, bud, which was recently shared on Reddit and you can watch the video:

https://www.youtube.com/watch?v=LoypcRqn-xA

Plenty of other frameworks which you have a specific framework is lacking in the Go ecosystem?

> #5 Fast compile time... which is an advantage over Python how exactly?

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).

You really don't need frameworks on go. You go and pick whatever tools you need like ORMS, http routers or loggers.

It is only a disadvantage if you want to have a framework.

you don't need frameworks in any language - the frameworks (for mature frameworks) are almost always modular enough that you can use the parts without the whole.

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.

Why skip on the other reasons listed? At least a few of them are technical in nature and don't warrant being omitted from your list.

“Performance” - looks like “I bought Ferrari instead of Hyundai because it faster”.