[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.