[NateDad]

My apologies, there didn't seem to be much to address.

> the only people who would use Go are people who aren't aware of the last few decades of compiler research: people who think coroutines are a new idea and aren't sure whether generics are useful

This is simply untrue. Most developers I know that like Go have written tens of thousands of lines of code in other languages that do have generics and more advanced features. You seem to assume that because people disagree with you, that they must just be ignorant. How about if people disagree with you because we have different tastes in languages? Some people love LISPs, they drive me crazy. Some people love Python, I think it's merely ok. ... I love Go, and you hate it. That's ok. I don't think everyone has to like Go. But I don't tell the LISP people they should drop all this paren BS. I don't tell the Python people that they should add braces and static typing to their language.

> what is it that you think people who want Go to have generics don't understand?

...that generics are not needed in many of the cases where they're used. That YAGNI holds true a lot more often than they think. I had actually started coming to this conclusion (about generics) before I even started writing Go - and I'd already started using them less. Not having foo<bar<baz>> in my code simplified it a lot, and given that most of the time I only ever implemented one version... it just wasn't worth defining a whole bunch of generic logic, when really I only had one concrete implementation that I'd ever use.

> My core complaint about Go: the authors simply have ignored decades of compiler research.

Not ignored, so much as "considered and discarded".

You say you've written Go and the lack of generics was a problem rather quickly. I have been writing Go for almost 2 years full time and 9 months on the side before that. Generics have almost never been a problem for me.

I see two possible reasons why we've had different experiences with Go:

Either you happened to be working on a project that really benefits from generics (something that makes heavy and repeated use of trees or vector/matrix math, etc)... or you were trying to write Go code the way you'd write in some language that does have generics.

If the former, well, that's truly unfortunate. Go doesn't work well for all projects. I wish it were better at that sort of thing, and maybe at some point we'll get some features that'll help out with those pain points. Maybe those features will be something like Generics... but I, for one, hope that it's not just generics like everyone else has generics, because I've been there, and I don't like it. There's a hell of a lot of code that doesn't need matrix math and left leaning red black trees and such. Go is good for all those projects.

If the latter, well, then you've really just shot yourself in the foot. This is like taking a minivan offroading in mud and then getting mad that it handles poorly. You have to use the language in the way it was designed. Yes, this means you probably have to write a min function every once in a while. Yes, this means you have to write a loop to test if a string is in a slice of strings. Just like you can't take the shortcut through the mud in the minivan. Just like you have to write type classes in haskell, or getters and setters in Java. Every language has its quirks.

All that being said, it's also completely valid fot you to say you just don't like Go. That's fine. I don't like a lot of languages, even though many other people do. But telling other people they're wrong or dumb for liking Go is not a position you can really justify. It's a matter of opinion, and opinions can't be wrong.

[codygman]

Every small min function that you ride has the potential to have bugs. In a language with generics there is only one min function meaning only one source of potential bugs.

So is it simpler to have all these little functions doing basically the same thing with the chance of bugs or 1 generic implementation that works for all of them?

Looking at things in this light bug potential in Go is O(n) whereas a language with generics is O(1).

The point being that without generics you end up implementing lots of these small similar functions and making lots of potential sources of bugs.

Idiomatic Go encourages writing easy and simple to fix code, which is good. However what I get for all this is go allows me to write the simple and easy to fix code that could potentially have bugs everywhere.

Hope this makes sense, haven't used voice typing for anything this large yet.

[NateDad]

Wow, if that's voice typing, I'm impressed, mine is never that good :)

I do understand where you're coming from. More code means more code that can have bugs, I totally agree.

However, more complicated code also means more bugs, and generic code is definitely more complicated and non-generic code (in all but the most simplistic cases). So, I don't think it's necessarily as straight forward as O(n) vs O(1).... and also for small values of n, O(n) is pretty close to O(1)... and my contention is that n is almost always small.

So, I don't think you're wrong, per se, I just think that in real life, it's not so black and white, and in my experience, the kind of code I have to duplicate is the dumb stuff, like min, which is nearly impossible to screw up, and if you do, it's immediately obvious in any kind of basic test of the surrounding code.

[tome]

> generic code is definitely more complicated

In Haskell at least this is usually not correct. A sorting algorithm with type

    Ord a => [a] -> [a]

(i.e. a generic one) is likely to be more neatly implemented than one of type

    [Int] -> [Int]

because the former can't use irrelevant properties of the type of the values contained in the list.

Perhaps you meant something different by "generic" though. There are a few subtly different uses of that word. One of them means a very neat and powerful generality as seen is Haskell's parametric polymophism. Another is a convoluted run-time tag-based dispatch mechanism which is often under-specified. I can imagine that programmers who have only ever seen "generic" code in the Python object oriented style (to take one example) think this style of "generic" code is more messy than "specific" code.

[codygman]

> Wow, if that's voice typing, I'm impressed, mine is never that good :)

I had to correct a few things, but I was pretty impressed by the accuracy :D

> I do understand where you're coming from. More code means more code that can have bugs, I totally agree.

Right, I find it easier to use very generic functions and compose them together. Go achieves some of this with interfaces, but my rub with that is that they aren't type safe IIRC. Which my experience has taught me is quite valuable.

> However, more complicated code also means more bugs,

No arguments here!

> and generic code is definitely more complicated and non-generic code (in all but the most simplistic cases).

Can we test this right now? Have any examples in mind so we could figure this out in code?

> So, I don't think it's necessarily as straight forward as O(n) vs O(1)....

I agree, I didn't mean for my statements to be taken as absolutes or perfectly accurate but more as a lens to look through.

> and also for small values of n, O(n) is pretty close to O(1)... and my contention is that n is almost always small.

I agree here, and this will lead us to the source of our (and many others disagreements).

I feel that when as much code is as generic as possible, I can make more generic code and lessen the potential points of failure.

Forgive the projection, but I feel your thoughts are more along the lines of "Really generic code isn't simple and simple code is the key to fast, easy to maintain, and well... simple code".

I was a big fan of Go in the past and thought along the same lines. I gave Haskell a try and things being very generic didn't seem to make complexity go up much to me.

This means it feels like a lot of Go proponents just dismiss Ocaml, Haskell, Scala, Clojure, etc as something convoluted and overly complex from the outside, but having spent some time in getting to know the language it seems just as simple or more simple than Go (although VERY different) in many areas (not deployment (Go does very good here) and I suspect not reasoning about performance but my use cases haven't necessitated enough profiling Haskell code to say for sure).

Just a random question, what do you and (if you don't mind guessing a little) other Gophers think of Nim? If I were to pick a dead simple imperative language along the lines of Go that didn't "ignore programming language research" I would pick Nim over Go unless there was a huge deficit in libraries for my use case.

[copsarebastards]

> You seem to assume that because people disagree with you, that they must just be ignorant.

If people disagree with me on things that are pretty solidly proven by my experience, then yes.

> How about if people disagree with you because we have different tastes in languages?

I mean, if you're argument basically comes down to, "That's just, like, your opinion, man", then I'd counter that its pretty objectively true that people are more productive in some language than others.

> ...that generics are not needed in many of the cases where they're used. That YAGNI holds true a lot more often than they think. I had actually started coming to this conclusion (about generics) before I even started writing Go - and I'd already started using them less. Not having foo<bar<baz>> in my code simplified it a lot, and given that most of the time I only ever implemented one version... it just wasn't worth defining a whole bunch of generic logic, when really I only had one concrete implementation that I'd ever use.

So your position is that we should take away features that people overuse?

There are tons of places where you just need a few functions, not a class with a bunch of methods on it. How far are you going to take this logic?

If you want to be babysat by your language, write Java.

> You say you've written Go and the lack of generics was a problem rather quickly. I have been writing Go for almost 2 years full time and 9 months on the side before that. Generics have almost never been a problem for me.

Well, there are a few explanations for that:

1. You've worked in a very narrow domain.

2. You're willfully pretending the problem doesn't exist so you can feel good about your chosen language.

3. You're completely not seeing the numerous cases where your code has duplication which could be removed using generics.

> You have to use the language in the way it was designed.

On the contrary, if the language is designed poorly I do not have to use it at all.

> It's a matter of opinion, and opinions can't be wrong.

So, lacking justification, you just segment off what you're saying into the realm of opinion, where if you believe hard enough anything you want can be true!

EDIT: A funny thing is that the Go core project itself is apparently not one of those projects you claim exist that don't benefit from generics. See here[1] about halfway down the page:

> A weakness of Go is that any generic-type operations must be provided by the run-time. Some day that may change, but for now, to make working with slices easier, Go provides a built-in generic append function. It works the same as our int slice version, but for any slice type.

But sure, that will never come in handy in most projects.

[1] http://blog.golang.org/slices

[NateDad]

> > You seem to assume that because people disagree with you, that they must just be ignorant.

> If people disagree with me on things that are pretty solidly proven by my experience, then yes.

I guess I just am aware that others may have had different experiences than I have, and unless their opinion is way out in left field (like, "programming in assembly is just as productive as python")... then I assume they're not ignorant. People think Ruby is fantastic and I think it's pretty horrible, but I don't think they're ignorant of other languages, they've just developed different tastes.

> So your position is that we should take away features that people overuse?

Some of them, yes. Go doesn't have the ternary operator. I consider that a good thing. I've seen critical security bugs that had been in production code for years because someone misused the ternary operator in a way that never would have happened with a boring old if/else.

> So, lacking justification, you just segment off what you're saying into the realm of opinion, where if you believe hard enough anything you want can be true!

I'm saying that what makes a language good or bad is generally subjective. I don't think you can objectively say one language is better than any other except in extreme cases. Is Haskell better than Python? Is C# better than OCaml? It's like asking if minvans are better than sports cars... it depends on what you want to do with them and what you enjoy. I used to like to floor it getting on the highway and hearing the engine rev as I was pushed back into the seat of my v6-powered sedan... now I take great satisfaction in throwing a new couch in the bed of my truck and not having to wait or pay for delivery. Is my truck better than my sedan was? Would my truck be better if it had the same 0-60 time as my old car? Sure... it would also cost like $15k more. There are always tradeoffs.

You say the Go community is being blind to the benefits of generics, and we say you're being blind to the costs of generics. And I don't mean compiler complexity or speed. I don't give a fig about the compiler. I care about the complexity of the code. I care about error messages that make you open up 4 different files to try to figure out what combination of code is actually being run in a single place.

I don't think we're going to agree here, and that's fine.