1. 21

  2. 1

    How many org ship Golang from HEAD? Only google? I think Uber has their own cherry pick fork?

    1. 2

      I don’t even think Google does! Even the Go team at Google runs most of their production servers on the latest released version of Go. I ran into an issue just the other day due to the Go module proxy being on Go 1.16 (but they’re upgrading to 1.17 soon).

      Edit: that doesn’t mean no one does, though. The Tailscale startup seems to.

    2. 1

      This is exciting! The biggest thing that has put me off Go so far has been the lack of generics. (I remember the days before generics made it into Java and I’m not too eager to re-live that experience)

      I understand the rationale for not including generics from the start, but as far as I can tell it leads to a lot of boilerplate and unsafe code. Especially in a language with good support for first-class functions, not having generics always felt like a missed opportunity.

      1. 6

        I’ve been writing Go professionally for a few years now, and lack of generics doesn’t result in “unsafe” code, at least not in the Go sense of memory-unsafe. It can result in runtime type assertion failures if interface{} types are used and converted at runtime. It can also result in boilerplate, with repeated (type safe) functions like ContainsInt and ContainsString instead of Contains[T] for slices. However, that happens less often than you’d think, as (unlike early Java), the built-in slice and map types are “generic” already (parameterized by type) … you just can’t add user-defined generic types or functions. This gets most people surprisingly far.

        That said, I’m cautiously optimistic about generics. They seem to be taking a typically Go-like caution with the features, not overhauling the language or stdlib with the introduction of generics. Still, I suspect there will be a raft of new “functional programming” libraries and other such things at first which won’t really fit in the Go spirit. Then hopefully it’ll settle down.

        1. 3

          I hope they don’t take too long with introducing the genetics to the standard lib. They risk a number of third party solutions filling the void. Best case, it will be like Apache commons. Worst case, like perl OOP. (I guess rust async frameworks are somewhere in between)

          1. 2

            it’s not entirely clear where you want generics to go in the standard library. the only real place i can think of is the sort library, and last thing i knew that was already being worked on. the go standard library isn’t filled with collections types or whatever like rust or c++. there really are only one or two files in the entire standard library where generics even could be added, much less would be useful. there’s a reason they hadn’t been added yet, and it’s because you don’t need them 99.9% of the time if you’re programming in go idiomatically, which the standard library generally does.

            my biggest fear with the introduction of generics is what is articulated in the parent of your comment, which is that everyone starts burying all of their code in a thousand layers of generic gibberish. the last thing anyone should want is for go to turn into c++. the fact of the matter is that at the moment if you find yourself “needing” generics in your go project, you’re probably doing something wrong, and you’ll either need to restructure your project in a better way, or, in the very few cases when you can’t do that (because you actually do need generics) you may have to hack around it. when the introduction of generics goes mainstream, you won’t ever have to hack around their absence when you really need them, but that doesn’t mean you shouldn’t refactor around their unnecessary inclusion. more often than not, reflexive use of generics is a matter of premature optimization, which your code (particularly in go) will be far better off without.

            i think a lot of people have this mistaken impression that all the philosophical “a bit of copying is better than a bit of dependency” etc etc stuff in the go community arose as some sort of coping mechanism for the lack of several important features. the opposite is true in reality: these “missing features” were deliberately left out for the purpose of incentivizing what the language’s developers believed to be a better style of programming. whether the costs incurred are worth the benefits is up for debate. at the very least it appears to be widely understood that some annoyances arise from that, particularly boilerplate, and that’s where generics and the various error handling proposals that aren’t set in stone yet have come from.

            here’s what that doesn’t mean:

            • best practices have meaningfully changed
            • every function needs type parameters
            • every file needs type parameters
            • every project needs type parameters

            if go as an experiment has taught us anything at all it’s that in the vast majority of cases you absolutely can go without all of these things we’ve convinced ourselves we need. if you find yourself thinking you need to use generics for a particular problem, the fact that you now can should not make you any less apt to pause and consider whether there really isn’t any other way to model the solution to your problem.

        2. 1

          I will say that Java’s solution to everything was inheritance + downcasting in the days before generics, and I think people mistakenly put all of the inheritance unpleasantness of inheritance into generics when thinking of the bad old days of Java. Go locks generics and that’s not great, but it still feels a whole lot better than Java 1.0. Notable Go also has type inference, first class functions, and structural subtyping which contribute a lot to the overall experience relative to Java 1.0.

          1. 1

            I’m mostly leery of generics, because I worry that it will lead to code which is hard to follow and reason about.