>By the time this decade rolled around, Node.js and Go had arrived on the scene, highlighting the need for concurrency as a first class concept. Various async contortions papered over the single threaded cracks of Python programs, but it was too late. Other languages had shown that concurrency must be a built-in facility, and Python had missed the boat.

While concurrency is nice, some citation is needed here. For one, Python is not going anywhere, and remains spectacularly more popular than Golang.

>But, no matter how important and useful templated types and immutability would be, integrating them into a hypothetical Go 2 would decrease its readability and increase compilation times—two things which Go was designed to address.

Well, they sacrificed compilation times to get a native compiler (which has no real utility to the users of the language, on the contrary it makes bootstrapping a little more messy).

Sacrificing it for Generics seems like a no brainer, but it seems they're not yet ready to bite the bullet.

As for "sacrificing readability" I don't think that having 30 lines of code just because you need to make it work with different types is any easier than having 10 lines of the same code with parametric types. Not to mention NOT having to write any code at all, because the standard library can finally have code (e.g for math, collections, etc.) that works across all relevant types. With Generics people could just reuse a few generic implementations of channel uses to handle 90% of their concurrency needs.

And it's also much better and easier to parse than using dreadful string templating kludges or interface{} to get the same behaviour.

I mean, the author mentions all those languages with generics ("Rust, Nim, Pony, Crystal, and Swift showed that basic templated types are a useful, and increasingly, expected feature of any language—just like concurrency"). Does he see the users of those languages complaining about generics being a burden?

Why do people always have to lament the terrible burden Generics will bring to Go in advance, when millions of us (literally, just add Java and C# programmers) just use generics in other languages without thinking twice about it?

There's a proverb in my country, that "He who'd rather not knead the dough (to make bread), keeps sifting the flour for days".

In programming terms it would translate roughly to: "He who is too lazy to build a bikeshed or doesn't like the prospect of building one, will keep on discussing the color it should give it".

Which I think is the case whenever anybody from the core Go team discusses Generics.

>As it stands now, generics or immutability can’t just be added to Go and still call it simple.

It's 2017. Neither are particularly difficult to grasp for a modern programmer. Even enterprise Java programmers have been using the former for a decade already, and they're not known for the wild experimental nature...