Well, it's been pretty productive for me. It's also been productive for Docker, InfluxDB, and Kubernetes (among other prominent, complex, open source projects).

Yeah it has also been productive for me. And we cannot forget Hashicorp's use of it for a lot of stuff.

Your comment will hardly lead to productive conversation.

The fact is a lot of people are perfectly fine with current Go capabilities and prefer writing useful software solution as compared to debating on PL theories and community agendas.

> The fact is a lot of people are perfectly fine current Go capabilities and prefer writing useful software solution as compared to debating on PL theories and community agendas.

How many? how many didn't use Go because it lacked of a sane type system? because Go relies way too much on runtime behavior (AKA type switches and reflection) to be called a modern statically typed language. In all my time using Java I never had to cast something once or use reflection, or to do a type assertion, all these are common practice in Go, especially when the std lib is now getting API like Context.Value(interface{})interface{}.

This isn't PL theory, these are flaws that aren't going anyway and will become more apparent as users will have to maintain all that "productive Go code" written 5/10 years ago. With Go the developers basically do the compiler's job manually. These problems are absolutely not going away, and people will write about how they ditched Go for these reasons.

You may not have used reflection in Java but we have a very large application in production which is heavily dependent on reflection. It is in use for many years and serves business purpose just fine. Could there be a better way? maybe, but a working solution now is better for our business than promised solution in remote future.

I think the striking point is that you're forced to use a throwaway to have an opinion.

I agree with you about Go's flaws. However, if you have never used a cast or reflection in Java, you have either not done much Java, or you have used libraries and frameworks that do the casts and reflection for you.

Absolutely. Many people will decide not to use Go for these reasons.

But others will come to the conclusion that things like complex name lookup rules, or generally too many possible interpretations of individual syntactical expressions, cause hugely greater mental load than any of Go's shortcomings.

That said, I have a lot of complaints about Go too. Especially error handling.

Almost every dependency injection framework in Java uses reflection extensively. And nearly every java project I've ever seen used one of them. Your claim that you didn't have to do reflection may be correct but I'm betting you were consuming code that used a lot of reflection.

Reflection is pretty predominant in java, even if you don't use it yourself. Many frameworks (like spring) rely on reflection to do their magic.

> The fact is a lot of people are perfectly fine with current Go capabilities and prefer writing useful software solution as compared to debating on PL theories and community agendas.

Citation needed. Has anyone actually done any sort of survey of users or potential users of Go to see what the opinion is regarding generics? How many would prefer Go with generics to Go without (I use Go almost exclusively at work, and would really appreciate generics, so there's at least one)? How many would prefer Go to not have generics? How many are ambivalent? If there is, could you please cite it?

I'm kind of frustrated by phrases like this being bandied about without evidence to back it.

You can certainly put some effort to create exhaustive surveys and ask people to take it.

For me existence of lot of software which are build with Go like Docker/Kubernetes and http based tools I develop and use it internally at work is good enough to assume Generics are not that important.

You'll never get that evidence; the type of people who are willing to fill out a survey are not the same type of people who don't care and are just Getting Things Done.

FWIW internally the Go team has a survey of all Googlers each year about why they are or are not using Go, but I am guessing even then getting responses about why they aren't is hard to come by.

I personally have other axes to grind that are much higher on my list (like os.File not being an interface) than generics.

Perhaps not in the short term, but I hope the comment does lead to some benefit in the long term, despite semi-religious attachment of some to a particular technology. Even the most flippant of downvoters will perhaps remember these words months or years into the future.

I don't use or particularly like Go, but I don't see what use is supposed to come from this. These comments aren't reasoned criticism — they just come across as bashing and sneering, as though you have some kind of grudge against a programming language. If you actually mean to contribute to the discussion, I think you might benefit from taking a few steps back.

No sneering involved at all, I assure you! Just an interest in programmer productivity, which I see as genuinely helpful.

Perhaps you see all languages as roughly equivalent and that is the cause of our differing opinions. In any case I've known quite a few engineers who have really drunk the koolaid, invested heavily in Go, become zealots for of the language and suffered for it before moving to options like Rust, Elixir, Kotlin or even Java or C++.

I'm just trying to prevent some of that suffering going forward. Nothing more nefarious than that!

Nah. Your post will be forgotten. You repeat the same tired old points - Go isn't Haskell/C++/Rust. That's correct, it's not.

Those complaints have been said a thousand times already, will no doubt will be said a thousand times more. And all will be ignored, as they should.

People generally need to see a message many times before it sinks in, especially if it's one they disagree with. Perhaps for you, there remain many more before any benefit is accomplished. That's okay.

It's also possible that your needs align particularly well with those of those who control the project. That's okay, too!