Six years of Go

As far as I know, goroutines are NOT green threads (threads managed by run-time environment instead of OS). Go produces native code (no VM). And, the goroutines can be multiplexed (depending on implementation) to OS level threads.

When it comes to computer science generics have been an accepted part of PL research for decades. The extra expression power they give and the paradigms they enable are neither controversial, not something that's up to individual tastes to judge.

Someone might not like them subjectively, but that's not different than someone not liking closures, or map or any other established thing. People will always have their preferences.

>I for one have spent the last 2 years using Go to build a very performant system which is used by thousands of Bitcoin day traders every day. It's fast, stable, and easy to modify. I have never felt held back by a lack of generics.

That doesn't prove it's not an objective issue, just that a specific use case, in a specific domain, didn't need it.

Or even more precisely, that a specific programmer didn't feel the need "held back" by their lack. Perhaps others would feel "pushed forward" by their presence.

For example, I mentioned Java above, who only got Generics after 10 years. Tons of far bigger Java programs than the one described have been created with Java-without-Generics (from financial services to automobile controllers).

All those projects weren't any "proof" that Java doesn't need Generics (and/or closures). Just that you can do without them too (which is true -- nobody argues that you can't).

Besides, isn't Paul Grahams whole "Blub" concept based on the idea that people using languages without X features have little means to understand their importance (and what they're missing)?

In any case, there are counter-examples to what you write too: several posts from teams that have used Go in production that say they like it but still lament the lack of generics.

>And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser" code, which can be more error-prone. In fact one of my favorite things about Go is how restrictive its type system is. I feel a lot more confident about my code doing only what I think it's doing when using Go.

Generics are not "loose", if anything they're even tighter type-wise than what Go makes you do to overcome their absence. Either you create concrete types for everything, ad nauseum, or you go "loose" and use interface{} and the like, throwing a lot of assurances out of the window.

>If the language is not for you, move on. There are plenty of us who are perfectly happy to write code without generics.

Again, happiness doesn't say much -- that's personal preference and can't be debated.

Java programmers were perfectly happy to write code without Generics and Closures for like 15 years too. Most were even oblivious that those things existed in the PL world at large. Javascript programmers suffered without correct scoping or an import system for 20 years, etc.

Green threads can be managed by a runtime library or VM, so no VM doesn't mean no green threads.

> the goroutines can be multiplexed (depending on implementation) to OS level threads.

Being multiplexed onto OS level threads is normal for green threads. Goroutines are "hybrid" (M:N) rather than "user-level" (N:1) threads, but anything other than 1:1 native threading means that you need a runtime or VM managing it, and its a kind of green threads.

I replaced python with go in my projects and i'm so happy!!!