1. 85

Update: changed title

  1.  

  2. 52

    Go has community contributions but it is not a community project. It is Google’s project. This is an unarguable thing, whether you consider it to be good or bad, and it has effects that we need to accept. For example, if you want some significant thing to be accepted into Go, working to build consensus in the community is far less important than persuading the Go core team.

    This is, essentially, not that different from how most projects work. Even projects which have some sort of “community governance” seldom have voting rounds where everyone can vote. Only contributors/core members can vote.

    Accepting all PRs is clearly not a good idea, so you need to do some gatekeeping. The biggest source of disagreement seems to be on exactly how much gatekeep is needed. The Go authors have pretty clear visions on what should and should not be in the language, and gatekeep a bit more than some other languages. Putting stuff in the language can also be problematic (see: Python’s := PEP drama).


    On the specific point of generics (sigh, again), I think the premise of that tweet is wrong. It suggests that the overwhelming majority of the community is just screaming for generics, and the Go Overlords stubbornly keep say “no”. That’s not really how it is. In the most recent Go survey 7% gave “lack of generics” as a response to “what is the biggest challenge you face today?” which is hardly overwhelming (although it’s not a clear “would you prefer to see generics in Go”, so not a complete answer).

    Anecdotally, I know many Go programmers who are skeptical or even outright hostile to the idea of adding generics to the language, although there are obviously also many Go programmers who would like to see generics. Anecdotally, I’ve also noticed that preference for generics seems negatively correlated to the amount of experience people have with Go. The more experience: the less preference for generics. I’ve seen people with a C# or Java background join our company and strongly opine that “Go needs generics, how could it not have them?!”, and then nuance or even outright change their opinion over the months/years as they become more familiar with the language and why the decisions were made.

    The author of that tweet claimed in the Reddit thread:

    I am suggesting that implementation of generics will be easy . All am suggesting is we (community) should implement prototype or so proof of concept and present it to committers .

    Which seems to suggest that this person is not very informed on the topic. The Go authors have been writing and considering generics for at least 10 years, and thus far haven’t found an approach everyone likes. You can reasonably agree or disagree with that, but coming in with “oh it’s easy, you can just do it” is rather misinformed.

    The Elm guy had a good presentation a while ago (“The Hard Parts of Open Source”) where he shared some of his experiences dealing with the Elm community, and one of the patterns is people jumping in on discussions with “why don’t you just do […]? It’s easy!” Most top-of-the-head suggestions to complex problems you can type up in 5 minutes have quite likely been considered by the project’s authors. They are not blubbering idiots, and chances are you are not genius-level smart either.

    This is also the problem with a lot of the “conversation” surrounding generics in Go. People like this guy jump in, haven’t seem to informed themselves about anything, and shout “why don’t you just …?!”

    Sidenote: I stopped commenting on anything Go-related on /r/programming as there are a few super-active toxic assholes who will grasp at anything to bitch about Go (even when the thread isn’t about Go: “at least it’s not as bad as Go, which [. rant about Go ..]”. It’s … tiresome.

    1. 26

      I think the premise of that tweet is wrong. It suggests that the overwhelming majority of the community is just screaming for generics, and the Go Overlords stubbornly keep say “no”. That’s not really how it is.

      Be wary of selection bias here: if someone really thought generics was important they wouldn’t be in your community to be asked the question. If the goals of the language are to serve the people already using it, thats a fine thing, but if it’s to grow then that’s harder to poll for.

      1. 10

        Every community is biased in that sense. People who dislike significant whitespace aren’t in the Python community, people who dislike complex syntax aren’t in the Perl community, etc.

        I don’t think the Go team should poll what random programmers who are not part of the Go community think. I don’t even know how that would work, and I don’t think it’s desirable as the chances of encountering informed opinions will be lower.

        1. 6

          Anecdotally, I’ve also noticed that preference for generics seems negatively correlated to the amount of experience people have with Go. The more experience: the less preference for generics.

          This part was also concerning to me. If Go is “blub”, then of course people who are more used to not having generics wouldn’t necessarily think generics are preferential.

          1. 8

            I don’t think this fits the “blub” model. People who have only used “blub” don’t understand what they are missing. But here we are talking about people who have got experience with generics: the more experience with Go they gain, the more they understand why Go does not have them.

          2. 2

            There is the old adage of being unable to please everybody.

            It’s better to cater to the crowd you have than the whims of random people.

          3. 13

            In the most recent Go survey 7% gave “lack of generics” as a response to “what is the biggest challenge you face today?” which is hardly overwhelming (although it’s not a clear “would you prefer to see generics in Go”, so not a complete answer).

            I think it’s also worth mentioning that “lack of generics” is the third biggest challenge in that survey (after “package management” and “differences from familiar language”).

            1. 7

              “I am suggesting that implementation of generics will be easy”

              Do you have a link to this comment? The way it’s phrased makes me think that it’s a typo and they meant to say “I am not suggesting that implementation of generics will be easy”.

              1. 8

                For outrageously inflammatory post titles like this one, I skip straight to the Lobsters top comment. Cunningham’s Law hasn’t failed me yet.

                1. 5

                  Reminder that Go has generics for a small set of built-in data types, just not user-defined generics. Let’s be explicit: the language already has generic types in its syntax, e.g.:

                  [n]int
                  []int
                  map[string]int
                  

                  It’s not a great stretch from this to something like tree[int]. Given this, the fact that the language designers have put it off for so long, and so much of the community is antagonistic towards it (where does that antagonism come from–where did people pick up on it?)–it’s not a big stretch to infer that they simply don’t want Go to have user-defined generics.

                  1. 5

                    where does that antagonism come from–where did people pick up on it?

                    I picked it up in the C++ community. From build times to breakage to complexity, I have repeatedly implemented external generics (code generation) solutions that were simpler to manage and gave far better results for my projects than using templates.

                    1. 1

                      Those are not really generic types but variable-length types. Not exactly the same.

                      it’s not a big stretch to infer that they simply don’t want Go to have user-defined generics.

                      The catch with your inferration (is that a word? Is now I guess) is that the Go authors have explicitly stated otherwise many times over the years, and have written a number of proposals over the years (the Go 2 Contracts proposal lists them). There have also been a number of posts on the Go issue tracker, Reddit, HN, etc. by Go authors stating “we’re not against generics, we’re just not sure how to add them”.

                      1. 3

                        Those are not really generic types

                        If you take a look at your linked design document, e.g. maps are repeatedly used as generic types in the proposed Go polymorphic programming design.

                        Go authors have explicitly stated otherwise many times over the years, and have written a number of proposals over the years

                        Good point, before the generics design document was published I suppose my inference would be more credible. Now I guess they are serious about generics–which seems unfortunate for the people you mentioned who vehemently hate them :-)

                  2. 15

                    It happened again last week. I sat down to write a program in Go, mentally grumbled to myself at all the boilerplate, if err != nil, fragile repetitive channel handling code, etc. … then snapped out of my coding trance six hours later with a working program that was fast and readable, and that I’d probably never have to touch again because it just works.

                    I don’t want to like Go, because I’m kind of a language nerd, but danged if it doesn’t do the job. So while I may not really understand how the core team thinks, I have to give them the benefit of the doubt.

                    Actually, I guess I do understand, because my formative years were spent in BSD 4.2 writing C code, and Go is just like a much more pleasant version of that. So maybe I’m wired to work that way. But I feel like it shouldn’t be as good as it is!

                    1. 6

                      I don’t want to like Go, because I’m kind of a language nerd, but danged if it doesn’t do the job.

                      This is exactly how I feel about Go as well. It is a language I want to hate, but when it comes to building apps, training people and handling annoying problems, it just does the job.

                      1. 1

                        I write golang and Clojure these days because those two languages give me results that Work. It’s a very important characteristic to have.

                      2. 15

                        In a way this is why I use Go. I like the fact that not every feature that could be implemented is implemented. I think there’s better languages if you’d want that. Don’t use a language either just because it is by Google.

                        Also I think that it is actually more the core team, than Google. I think that Go if it was the company would be much different, than we have now. It would probably look more like Java or Dart.

                        One needs to see the context. Go is by people with a philosophy in the realms of “more is less” and “keep it simple”, so community wise closer to Plan9, suckless, cat-v, OpenBSD, etc. That is people taking pride in not creating something for everyone.

                        However unlike the above the language was hyped a lot, especially because it is by Google and especially because it was picked up fairly early, even by people that don’t seem to align that much with the philosophy behind Go.

                        I think generics are just the most prominent example of “why can’t I have this?”. Compare it with the communities mentioned above. Various suckless software, Plan9, OpenBSD. If somehow all the Linux people would be thrown onto OpenBSD a lot of them would probably scream to Theo about how they want this and that and there would probably be some major thing they “cannot have”.

                        While I don’t disagree with “Go is owned by Google” I think on the design side (and generics are a part of that) I’d say it’s owned by a core team with mostly aligned ideas. While I also think that Google certainly has a bigger say even on the design side than the rest of the world I think the same constellation of authors, independently of Google would have lead to a similar language, with probably way fewer users, available libraries and I also don’t think Docker and other projects would have picked it up, at least not that early.

                        Of course there’s other things such as easy concurrency that could have played a role in adoption, but Go would probably have had a lot of downsides. It probably would have a lot less performance improvements and slower garbage collection, because I don’t think their would be many people working so much in that area.

                        So to sum it up. While Google probably has a lot of say, I don’t think that is the reason for not having generics. Maybe it is even that Go doesn’t have generics (yet) despite Google. After all they are a company where a large part of the developers have generics in their day to day programming language.

                        EDIT: Given their needs I could imagine that Google for example was the (initial) cause for type aliases. I could be wrong of course.

                        1. 8

                          it was picked up fairly early, even by people that don’t seem to align that much with the philosophy behind Go.

                          Personally, I think this had a lot to do with historical context. There weren’t (and still aren’t, really) a lot of good options if you want a static binary (for ease of deployment / distribution) and garbage collection (for ease of development) at the same time. I think there were a lot of people suffering from “interpreter fatigue” (I’ve read several times that Python developers flocked to Go early on, for example). So I think that, for quite a few people, Go is just the least undesirable option, which helps explain why everyone has something they want it to do differently.

                          Speaking for myself, I dislike several of the design decisions that went into Go, but I use it regularly because for the things it’s good at, it’s really, really good.

                          1. 5

                            There weren’t (and still aren’t, really) a lot of good options if you want a static binary (for ease of deployment / distribution) and garbage collection (for ease of development) at the same time.

                            Have you looked at “another language”, and if so, what are your thoughts?

                            1. 4

                              Not a whole lot. My superficial impression has been that it is pretty complicated and would require a pretty substantial effort to reach proficiency. That isn’t necessarily a bad thing, but it kept me from learning it in my spare time. I could be totally wrong, of course.

                            2. 4

                              There weren’t (and still aren’t, really) a lot of good options if you want a static binary (for ease of deployment / distribution) and garbage collection (for ease of development) at the same time

                              D has both.

                              1. 2

                                I completely agree with your statement regarding the benefits and that this is certainly a reason to switch to Go.

                                That comment wasn’t meant to say that there is no reason to pick up Go, but more that despite the benefits you mentioned if there wasn’t a big company like Google backing it, it might have gone unnoticed or at least other companies would have waited longer with adopting it, meaning that I find it unlikely it would be where it is today.

                                What I mean is that a certain hype and a big company behind is a factor of this being “a good option” for much more people, especially when arguing for a relatively young language “not even having classes and generics” and a fairly primitive/simple garbage collector in the beginning.

                                Said communities tend to value these benefits much higher than the average and align very well in terms of what people emphasized. But of course it’s not like one could be sure what would have happened and I am also drifting off a bit.

                            3. 10

                              Honestly, something like “OpenGo” would probably turn out to be rather annoying, especially if fragmentation such as Go with and without generics would come about, or even worse Google’s Generics and OpenGo’s generics.

                              1. 4

                                what would probably be nicer for everyone concerned is a couple of good compile-to-go languages, analogous to e.g. typescript and clojurescript which provide respectively incremental improvements to js and a radically different language that can interoperate with your js code, and neither of which have forked javascript.

                                1. 4

                                  There are a bunch of little projects like that floating around, and a number of them work much better than you would expect, but none have really ignited any sort of excitement.

                              2. 5

                                Ian Lance Taylor (one of the core Go people) just posted an interesting reply to this to the go-nuts email list:

                                https://groups.google.com/forum/#!topic/golang-nuts/6dKNSN0M_kg

                                1. 3

                                  How come “(benevolent) dictator for life” is OK for pudgy but lovable Western European men, but is not ok for corporate entities from the USA?

                                  1. 63

                                    Shall I compare thee to a billion-dollar corporation? Thou art more lovely and more temperate,

                                    1. 12

                                      Because ultimately, when the community VERY LOUDLY made it known to Guido that type system theory may be a fascinating pursuit but that radically altering the Python language to sprout that kind of feature isn’t something some people are interested in, he stood aside and allowed the language governance to change to meet the needs of the community.

                                      What I’m reading from this article (Not a Go fan, no skin in that game. Feels like a time warp back to K&R C circa 1988 to me.) is that there is exactly zero chance of this ever happening with Go.

                                      1. 5

                                        when the community VERY LOUDLY made it known to Guido [..], he stood aside and allowed the language governance to change to meet the needs of the community.

                                        Wait, you tout it as a good thing? Being very loud rarely has anything to do with being right or useful. And making a smart person cave in to harsh pressure is not really an achievement.

                                        (Mind, I’m not discussing the technical point about types itself.)

                                        1. 3

                                          From my perspective, despite the phrasing I chose in my previous comment, this isn’t at all about being loud.

                                          It’s about defining the technical direction of a piece of technology that is used and relied upon by a vast number of people with very varied use cases.

                                          Nobody is saying that Guido shouldn’t design type theory oriented extensions to Python, what people are objecting to is radically altering the syntax of the language standard in order to further those goals.

                                          For many people, what we value about Python is its un-clever, un-cluttered syntax, and for a substantial number of people, the directions Guido wanted to take the language were not conducive to our usage patterns.

                                          My point here is simply that Guido, as language designer, was mature/enlightened enough to put his ego aside and recognize that the directions he wanted to take things were not what a sizable numerical percentage of the community wanted, and that his energy would be best spent standing aside and letting majority rule. I see this as a very different situation from the one you paint in your comment.

                                          1. 2

                                            Now, that is a much better explanation, thank you!

                                            Despite being a long-time user of Python I was never involved in the design discussion around the language, so I only see what other people translate outside of the inner circle.

                                        2. 3

                                          Isn’t that exactly what happened? The community said they needed module support, the go team added module support.

                                          1. 11

                                            Again, not an expert - not even a Go fan - but what I’m reading is that the community came up with its own solution and the Go team chose a radically different path.

                                            So, maybe? I’m not sure. The point I was addressing was the “Go is Google’s, not the community’s”.

                                            1. 2

                                              Not in that way, though. There were a few community solutions to packaging over the years when the Go team didn’t want to tackle the problem, leading to one solution (dep) that was basically officially blessed right up until it wasn’t and another path was chosen by the core team. There was poor communication around this and expectations were not well managed. I think the go team truly wants the best solution, but seeing this play out did make some people feel like the author of this post.

                                              The bigger issue is that the priorities used to design go modules are quite different from what some folks in the community want in a dependency manager (specifically, its use of minimal version solving), which puts you in the position to use the official thing that doesn’t do what you want or try to find a community-backed project that is attempting to work in a familiar way but will surely dry up as folks adopt the official solution.

                                              FWIW I had a bunch of issues with dep, but I think they were the result of not having a centralized repository for packages like there is for other languages and with not the tool itself. It turns out that it’s hard to build a reliable dependency manager when you need to be able to contact every host who hosts code instead of just one.

                                          2. 7

                                            Because modules.

                                            (Seriously, I read the whole post as a complaint about the modules decision it alludes to, plus the obligatory swipe at the lack of generics.)

                                            1. 5

                                              You’re probably correct.

                                              I, for one, am happy with modules. I never liked dep, and think modules is significantly better both in semantics and implementation. That being said, some of the communication was … unfortunate, although different people seem to have quite different recollections of some events, so who knows 🤷

                                              I do empathize a lot with the dep team (And Sam in particular) as it always sucks if you spend a lot of time on something, only to not have it used. But sometimes these things are hard to avoid.

                                              1. 3

                                                I don’t think I made it clear enough that my entry was an observation, not a complaint; to the extent that it’s a complaint, it’s only a complaint that the Go team is not honest about how things work in Go’s evolution. I personally am happy with the end results of the current Go module design (as a sysadmin, I particularly like the minimum necessary version approach) and the current lack of generics (I would rather have no generics than not-great generics or generics that clash with the rest of the language). There are a number of benefits that come from having a language with a distinct ownership, provided that you have the right owners, and I think that Go does.

                                                (I’m the author of the linked-to entry.)

                                              2. 3

                                                It sounds like the complaint is that Google talks a big game about how open Go’s development is, but at least in the modules case, is happy to completely ignore extensive open coordination on building a module system for Go while silently building its own module system from scratch. I don’t follow Python development that much, but I don’t think they’ve ever done anything like that.

                                                1. 0

                                                  It’s really not ok for either, to be frank.

                                                2. 3

                                                  Probably a good idea. Design by committee will just create languages that are all one big grey brown blob like all colours mixed together.

                                                  1. 2

                                                    At the end of the day, languages which don’t have a BDFL tend to implement a lot of bad things. Unfortunately, the opposite side is that languages with a BDFL definitely miss out on good things here and there as well. I think that having a team focused on the BDFL job is even better, so this isn’t necessarily bad even if it’s “Google’s language”. It can still be ours, as is the nature and explicit role of open source.

                                                    I think that the productive take-aways here fall into knowing how this it’s a team who cares a lot about the brain decisions in this language and wants excessive discussion before implementation. It seems that the Go team wants strong detailed proposals, and the open source community will have to find a way to make that work.

                                                    It seems quite shady at best for Russ to write their own implementation without any discussion - and that sucks if they require the opposite from contributors - but hopefully everyone learns from this to help the language and community grow.

                                                    Surely they know how this looks on their side, and it ain’t good. Starting wars, though, is not helping anyone.

                                                    1. 1

                                                      I see split opinions on this in the comments, but I’ll pose the question: should language development be centralized or decentralized? I suppose this gets at what you want out of a language, but I don’t believe language devs are the special people that only authorized to extend and support said language. Is that a common view?

                                                      1. 8

                                                        My limited knowledge suggests that each successful language is the product of a single person or a small team under the leadership of one or more people with a strong vision of how the language should be developed.

                                                        I’m certainly no expert however and welcome counter-examples.

                                                        1. 4

                                                          At a certain point I think you would indeed get a “too many cooks” problem, especially in cases where there wasn’t a small leadership team of some kind (BDFL, core team, elected core team, etc) to make decisions on things that don’t have clear (or mixed) consensus.

                                                          Whether or not that small leadership team should be beholden to a single company or not is certainly debatable.

                                                          1. 2

                                                            Wouldn’t Lisp be the ultimate counter-example to this? I’ll be the first to say the myriad of dialects is both a blessing and a curse.

                                                            1. 2

                                                              Wouldn’t Lisp be the ultimate counter-example to this?

                                                              It totally fits the parent comment if you look at its history. The defining works early on were a one-person paper, a one-person implementation, and a two-person compiler. If that article is right, that’s about four people getting it going after one laid down the key ideas. From there, there were various teams of bright people building Lisp’s and Lisp Machines. I don’t know what happened from there.

                                                              Likewise, the best implementation of Scheme is said to be Chez Scheme. Another small team. Racket was an unusual case that maybe didn’t fit depending on how the actual contributions worked out. There was a whole affiliation working on it.

                                                              1. 1

                                                                Would you label Lisp a success? Really depends on how you judge a successful language at the end of the day.

                                                                1. 1

                                                                  Sure.

                                                                  Maybe not by the larger world’s standards, but those don’t mean a whole lot to me.

                                                                  1. 2

                                                                    I guess my question is – what is YOUR standard? What defines successful of a language for you?

                                                                    1. 1

                                                                      It’s successful because it permanently affected how I think about programming; namely the idea that a few simple concepts could compose in such a way to afford an high degree of expressivity for those that wish for such things. And also the idea that the implementation itself can be relatively simple.