1. 6

  2. 7

    I’ll admit to not reading past “lack of generics”.

    1. 2

      I don’t dismiss go out of hand for lacking generics, but it does kind of irk me. I would like to have a red-black tree of Things, not a tree of {}.

      1. 3

        I meant in terms of a criticism; mostly because that topic has been so thoroughly played out on the mailing lists and in other discussions. No criticism in the past six months (or longer) that I have read has added anything productive to the discussion. I guess I just get sick of reading what comes across as whining at this point.

        I did end up reading the whole thing, though.

        1. 2

          ah, if you had phrased that as “tired argument is tired” I would have understood. :)

          1. 1

            I don’t follow go news, do you have any links that sum up the main points of both side?

            1. 2

              old but possibly useful reference: http://research.swtch.com/generic

              1. 1

                I don’t; I’m sure searching the Go-Nuts mailing list will yield plenty of results. Essentially it boils down to one said saying “how can you not have generics?” and the Go team responding, “we’ll support generics once we find a good way to do it.”

        2. 3

          Seems wrong on main complain “Confusing Semantics Of Exported Identifiers”, that is not a problem rather that enables good public API design.

          1. 1

            As a recent convert to Go, here are my thoughts…

            The type system is just different. It does feel unlike other languages I’ve used, and it can feel a bit unintuitive at times. For instance, parsing a lot of arbitrary JSON feels like falling into a quagmire of type assertions. My code quickly turns into a wall of text like this:


            I know parsing JSON in any typed language can be a pain. I’m still not sure if there’s a better way to do that?

            The other bits that feel confusing is when you can use type conversions vs type assertions. Also, at first glance anonymous fields create types that walk & talk like a Foo, but can’t be converted to a Foo. It took me longer than it should have to realize that the anonymous fields can still be referenced directly. In general, the type system works for me in all the code I write for myself; the only times I’ve had real trouble wrestling with types is when I’m trying to integrate with a library that wasn’t designed to be used the way I was trying to us it. More often than not I feel like I’m trying to fit a square peg into a round hole – as I’m starting to write more library code myself I’m trying to get a better handle on best practices for good go library design.

            As far as Exported Identifiers, the only issues I’ve had were writing a large amount of code with a non-exported field name and then realizing later that I wanted it exported (or vice-versa). The change turns into an O(n) update for every usage of the field as opposed to an O(1) update at the declaration of the field. It just catches you at build time when you miss a reference somewhere, it’s not a big deal as long as you don’t have a long build time. Once again it kinda goes into building a good library from the start – the cost of making a poor API decision early on can translate to a lot of work later trying to fix it.

            1. 8

              You shouldn’t be using JSON like that. You should be defining structures in your program that mirror the data you expect to receive, json.Unmarshaling into them, and accessing the struct fields directly.

              1. 3

                As peterbourgon mentions below, you shouldn’t be unmarshalling everything into a map[string]interface{}, as you lose compile-time type safety.

                If you’re unsure of the JSON that you’ll be receiving, at least use something like mapstructure which will return sensible errors when decoding fails.

              2. 1

                To me the thing stopping me from using Go is that you can’t write shared libraries with it: https://code.google.com/p/go/issues/detail?id=256 I generally work in python (although a lot of lua lately) and I’d like the option to rewrite CPU intensive bits in go rather than C. However, using go isn’t possible.