If you consider the adoption rate, it's pretty clear that the people who avoid Go because of <insert missing feature> are a vocal minority.

Can you point me to a survey that shows that a majority of developers would like to try Go? If not, how can you be so sure that those who avoid it because of <insert missing feature> are a minority?

As a counterpoint, here's a survey that suggests that only 14.54% of developers have any interest in learning Go. How many of those who don't are turned off by lack of features? I don't know, but I'm not sure how you could either.

https://insights.stackoverflow.com/survey/2021#most-loved-dr...

Why are you saying "only"? Are we looking at the same list?

Personally I considered it something of a feature that Go repelled people who prioritized "writing in their personal style" or "showcasing their powers of abstraction" above all other concerns. The result was standard, readable, boring code which made Go a very productive tool.

While true, that doesn't really change the situation for the individuals who require <missing feature>

No one meaningfully "requires generics", people are just reluctant to set their ego aside and learn a different approach. Some use cases may benefit from generics, but even then "require" is too strong.

Honestly, one of the biggest things that drives me away from Go isn't the lack of features, it's this condescending attitude that comes from so many people who espouse Go. I don't need to invest in a language whose community is so hostile.

If you wanted to be persuasive or helpful, you could try explaining what the other approaches to work around lacking generics might be, rather than just insulting people for being unable to figure out on their own how to avoid copy/paste spamming their codebase.

> Honestly, one of the biggest things that drives me away from Go isn't the lack of features, it's this condescending attitude that comes from so many people who espouse Go.

I could say the same about many of Go's critics, but I don't because that wouldn't be constructive. Rather than taking undue offense at my comment, why not articulate a counterexample to prove that there are valid reasons why a person (rather than a use case) might require generics?

> If you wanted to be persuasive or helpful, you could try explaining what the other approaches to work around lacking generics might be, rather than just insulting people for being unable to figure out on their own how to avoid copy/paste spamming their codebase.

Because these are already well-understood and have been debated to death. Instead of .map().filter().flat_map().reduce() you use a simple for loop. Instead of `LinkedList<ItemType>` you use `type List struct { Item ItemType; Next List }`. The thing that we generally aren't* agreed on is whether those extra characters are actually the end of the world versus the benefits associated with simpler, more concrete, more standard code.

Anyway, I wasn't "insulting" anyone, I was describing Go critics' objections in roughly their own terms (i.e., in so many conversations I've had with Go critics esp over generics, the conversation eventually terminates at some variation of "Go forces me to think about programming differently than I'm used to").

> simpler, more concrete, more standard code.

All three of these things are subjective.

> in so many conversations I've had with Go critics esp over generics, the conversation eventually terminates at some variation of "Go forces me to think about programming differently than I'm used to"

At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is.

>At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is.

This justifies anything popular, including things that are now universally seen as bad, but once were popular.

In the context of a discussion about programming languages, no, it really doesn't. Not all slopes are slippery.

It seems like it does to me. Why doesn't it?

Because not all statements apply to all situations.

This is really vague and unhelpful. I’m going to interpret this to mean you’re not interested in actually explaining the problem, sorry if I’m mistaken.

There's not really any further way to "actually explain" that, often, when a person says something, context matters and it isn't universally applicable.

I'm not even sure why I'm having to explain this. It's is a pretty obvious thing.

Obviously its not obvious to me. I've had enough of your games, if you're interested in an actual productive conversation, feel free to reply, otherwise I want nothing to do with you.

For what it’s worth, this is the read I’ve gotten from this thread as well. I’m not sure how else to interpret the parent’s remarks—his responses seem evasive rather than clarifying.

Yea I noticed that in your interactions with them too. Also while I’m here I want to compliment you on your articulations of the strengths of go throughout this comments section! They’ve been very well put/compelling and helped me understand better how to express the things I like about go in the face of its detractors, which is a constant struggle for me.

> All three of these things are subjective.

Not really. They aren’t formally defined, but there’s pretty wide consensus even among Go detractors about these qualities.

> At some sufficiently large number of people, you need to acknowledge that how they think isn't wrong, the language is.

Not when there are plenty of people willing to think differently and reap the benefits.

> there’s pretty wide consensus even among Go detractors about these qualities

[citation needed]

> there are plenty of people willing to think differently and reap the benefits

"Reap the benefits" is, again, subjective. It's something you like, not something objectively beneficial or worth the trade-offs in all, most, or even necessarily many projects.

This is precisely the unduly arrogant attitude amongst Gophers that others have already mentioned several times in this thread.

You’re welcome to disbelieve me on the consensus. I’m not trying to persuade you of anything.

> "Reap the benefits" is, again, subjective. It's something you like, not something objectively beneficial or worth the trade-offs in all, most, or even necessarily many projects.

Of course, productivity isn’t for everyone. Sometimes for personal projects I’ll opt for things that exercise my creativity and cleverness over the purely productive or pragmatic.

> This is precisely the unduly arrogant attitude amongst Gophers that others have already mentioned several times in this thread.

Hah! This made me laugh. Yes, I disagree with you therefore I must be arrogant. (:

lol...you even take criticism arrogantly. Impressive. It wasn't a personal attack, it was a statement of fact, but thanks for making my point even more clearly for me - not only in your response to that, but in your assertion that your opinion based on your experience is fact. Appreciated.

Restated: You aren't arrogant because you disagree with me. You're arrogant because the things you say and the way you say them are arrogant.

Look, I’m not interested in a slapfight. Enjoy your evening.

Considering the alternative is often either "copy and paste a bunch of code with a type changed in a bunch of places and commit the result" or "vtable dynamic dispatch", it's perfectly fair for a person to say that they require that feature.

Generics also aren't the only useful feature that Go lacks (or, as of today, lacked).

You still don't "require generics", you might require more performance than idiomatic Go offers, but in this case you're also excluding everything slower than C/C++/Rust irrespective of whether or not the language supports generics.

> Generics also aren't the only useful feature that Go lacks (or, as of today, lacked).

Agreed, but it's foolish to frame language debates purely around the presence or absence of useful features. Many languages have too many features including a great many misfeatures which degrades the overall experience, and your analysis doesn't account for that. Further, there are costs associated with things like generics which your analysis similarly ignores. Further still, it ignores things like tooling, ecosystem, learning curve, etc. This is how you end up with C++.

> You still don't "require generics", you might require more performance than idiomatic Go offers, but in this case you're also excluding everything slower than C/C++/Rust irrespective of whether or not the language supports generics.

Performance only drives one of the two alternatives.

> Agreed, but it's foolish to frame language debates purely around the presence or absence of useful features. Many languages have too many features including a great many misfeatures which degrades the overall experience, and your analysis doesn't account for that. Further, there are costs associated with things like generics which your analysis similarly ignores. Further still, it ignores things like tooling, ecosystem, learning curve, etc. This is how you end up with C++.

This isn't an analysis. It's a counterpoint to a single individual on a social media website.

Go's ecosystem and learning curve are great. The best thing I can possibly say about its tooling is "it's better than C and C++". Seriously, how many dependency management paradigms have we gone through so far, and the best thing we can come up with is `go mod`?

> Performance only drives one of the two alternatives.

Right, so use dynamic dispatch by default.

> Seriously, how many dependency management paradigms have we gone through so far, and the best thing we can come up with is `go mod`?

Agreed that the road to go mod has been tumultuous, but go mod is in the top tier of dependency managers, which is perhaps a sad indictment of dependency managers. Most languages still don’t offer reproducible builds, and several mainstream languages require that you generate your list of dependencies in an imperative DSL—or at least these build systems are the most popular, which brings us to another problem: some languages don’t even have a single standard tool! From dependency managers, let’s look at build tools: how many build completely static binaries by default? How many make you script the build in an imperative DSL? How many punt altogether? How many languages compile to native code in seconds or faster? How many languages can trivially cross-compile virtually any package? How many languages still make you spin up a CI job to build and publish source code packages? How many make you spin up a CI job to build and publish documentation packages? How many support testing out of the box? Benchmarking? Fuzzing? Formatting? Profiling?

As far as I can tell, Go trounces virtually every other language on tooling (Rust seems to do pretty well). One area where ago doesn’t do as well is debugging—I know Go has delve, but I understand it to be limited (haven’t tried it in a long time though to be honest).

You can dig a hole of any size with a shovel, given enough time. But I wouldn't fault people who refuse to dig a large hole with a shovel after they've seen an excavator at work.

This analogy just reduces down to “I think generics are more fit-for-purpose” which is just another way of saying “I think generics are better”. And I certainly think there’s a fair amount of merit to generics, but the folks who have seriously programmed with and without generics are much less fervent supporters of generics (if they support them at all) than the generics-advocates who have only used languages that make heavy use of them. I won’t try to analogous this to power tools or cars or anything else because such analogies are never enlightening and usually at least a little corny.

Well, I can only speak for myself :)