8 ms·

Why are functions like cap, len, and close builtins instead of library functions? Is it because they have to be generic over channel types?

kasey_junk 10y ago
Yes. Same for slices & maps. Go's generic support must be built into the language.
hamandcheese 10y ago
Because the creators won't give us generics
- duaneb 10y ago
  ...yet.
- dispose13432 10y ago
  I know it's a controversial point among users, but I think that if Generics were such a show stopper, Google would have implemented them. Go was invented for internal Google use, and then shared with the world, and Google is an engineering company. If engineers would have rebelled, higher management probably would have done something about it. ----- Although I don't understand why they keep fighting it. A simple style generics (Java style) shouldn't make code that ugly.
  - unscaled 10y ago
    Generics are not a show stopper, since they already exist (built-in support) for everything the language creators care about. Whether or not they are a show stopper for the users - well, that depends on your use case and preferences. Since show stoppers are a subjective thing. Objectively you could implement everything in Assembly or even Machine code, and people used to write rather complex programs this way. I personally know there are a lot of types of systems I would never implement in Go if given the choice, because it would be too bothersome, and I don't like RSI. YMMV.
  - catnaroek 10y ago
    Parametric polymorphism alone is a simple yet very powerful feature, but this assessment changes drastically as soon as subtyping (which both Go and Java have) enters the picture. The combination of parametric polymorphism and subtyping creates the pesky issue of determining whether Foo<T> should be a subtype of Bar<U>. Java-style generics are a lot of things (notably “bolted on”), but “simple” certainly isn't one of them. Wildcards are complex. F-bounded polymorphism is complex. Non-denotable types are complex.
    - pcwalton 10y ago
      Go doesn't have subtyping. It has coercions, which are not the same thing, and they do not lead to issues around variance. Variance is straightforward anyway. A lot of things in Go, like the semantics of "nil" and zero values, are more complex than variance. And, as a designer, if you're worried about the complexity, just make all type parameters invariant, like C++ does. It's a bad excuse to not have generics at all. Rust works exactly the same way as Go (coercions, no subtyping), except that there is subtyping in Rust via the region system. But Go doesn't have that. No region system, no subtyping.
      - catnaroek 10y ago
        What distinction between coercion and subtyping are you making? Aren't Go structs subtypes of every interface they conform to? And I don't think making all type parameters invariant eliminates any complexity. It just pushes it onto the user.
        burntsushi 10y ago
        It would be the other way around. It is intuitive to say that interface{} is a subtype of all other types, but it is easy to show a contradiction. Assume that interface{} is a subtype of int, which means interface{} can be used in place of int in any type. So define a function with type func(xs []int). If you pass a []interface{} to this function you will get a type error. More concretely, []int and []interface{} have different in memory representations.
  - closeparen 10y ago
    Do we know that Google actually uses Go extensively? AFAIK the Downloads web server is the only piece of Google publicly disclosed to be written in Go. IIRC most of Google is C++ and Java, which both have generics.
    - eggie5 10y ago
      Kubernetes is written in go
      - kasey_junk 10y ago
        Is kubernetes widely used at google?
        vitus 10y ago
        In short, yes. How else would we provide scalable containerized services? Docker?? [0] [0] Don't be silly, of course we rolled our own.
        lobster_johnson 10y ago
        Not widely, as far as I know. Google has two existing systems, Borg and Omega, whose ideas were distilled into Kubernetes. According to an answer on Quora in May [1], Kubernetes is only used for some things that run on the Google Cloud Platform. Some more background here [2]. [1] https://www.quora.com/Does-Google-use-the-Open-Source-Kubernetes-or-a-version-of-Borg-for-their-own-container-management https://www.quora.com/Does-Google-use-the-Open-Source-Kubern... [2] http://queue.acm.org/detail.cfm?id=2898444 http://queue.acm.org/detail.cfm?id=2898444
        Cyph0n 10y ago
        That's pretty disappointing honestly. So which container management platform is actually used at scale?
        lobster_johnson 10y ago
  - deleted 10y ago
    [deleted]
  - scottlamb 10y ago
    > Go was invented for internal Google use, and then shared with the world, and Google is an engineering company. If engineers would have rebelled, higher management probably would have done something about it. Not necessarily. Go was invented for internal Google use, but most of Google's code is still in C++ and Java. New projects are often started in C++ and Java, even, as they depend on libraries written in those languages. I think this would be true even if Go were perfect; switching languages is hard. But it means you shouldn't assume Google has solved whatever problems one would encounter while implementing Google product X in Go. Or that all Google engineers believe Go is a good language; as with any large group of programmers, there are people with opposing viewpoints about the virtues of various programming languages. Google management doesn't tend to impose top-down technical decisions such "product team X must use Go" [1] or "the Go team must add language feature X". They generally give broad direction and then trust the engineers doing the work to find the best technical approach to accomplish the task. [1] Although you generally must stay within the handful of approved languages: C++, Java, Go, JavaScript (for frontend stuff), Python (mostly for internal stuff, and getting less socially acceptable over time). One reason for this list is that when you write a Google system in a new language, you need a bunch of support from the rest of the company to do it: build infrastructure, libraries, etc.
  - twic 10y ago
    > Go was invented for internal Google use Go was invented by a small group at Google with the aim of solving some of Google's problems as they saw them. It's not as if the whole of Google came together and collectively designed the language they needed. I wouldn't read too much into the fact that it happened to be invented at Google, rather than wherever else Rob Pike happened to be working at the time.
- ridiculous_fish 10y ago
  An alternative design that does not require generics is to make channel types implement a Channel interface, which has methods close(), len(), etc. This seems less magical, and would enable functions that act on channels as existentials. Why generic builtins instead of a Channel interface?
  - shurcooL 10y ago
    To answer your question, from the Go FAQ [0]: Why is len a function and not a method? We debated this issue but decided implementing len and friends as functions was fine in practice and didn't complicate questions about the interface (in the Go type sense) of basic types. Also worth noting is that debate happened in 2009 or earlier, which is 7 years ago. After that, Go 1 has been released with its promise/guarantee of compatibility [1], so changing the language is not possible. It is what is, and significant language changes can only happen in Go 2. Until then, many, many people and companies are using Go 1 with huge success and happiness and have built great things with it. In practice, I find it works really well. [0] https://golang.org/doc/faq#methods_on_basics https://golang.org/doc/faq#methods_on_basics [1] https://golang.org/doc/go1compat https://golang.org/doc/go1compat
    - frou_dh 10y ago
      It's a bit of a mindfuck coming from mainstream OO languages that none of Go's built-in types have any methods† I guess there's a certain cleanliness whereby all methods exist on one side of the language/library dividing line. † The sole exception perhaps being "error", which is a pre-declared interface comprising 1 method. --- In a similar vein, this takes some getting used to: x.append(y) # No! append(x, y) # Probably Not! x = append(x, y) # Yes! (but this is not Lisp - despite appearances, the collection is mutable)
      - kazinator 10y ago
        If the object held in x is already mutable, why do we have to assign the returned value back to x also? Ah! Beacause it is like Lisp? (setf x (nconc x y)) I.e. the empty list cannot be mutated to non-empty, but non-empty can mutate to different non-empty. Surely, we could wrap append with a appendf (append functional), such that we can do: x = appendf(x, y); # no mutation: original x preserved Inside appendf we might have to do something gross, like duplicate the entire object, and append to the copy.
- Animats 10y ago
  Go has generics, or at least parameterized types. Maps and channels are generics. Go just doesn't have user defined generics.
  - anonymoushn 10y ago
    So C has generics?
    - kzrdude 10y ago
      Why?
      - zielmicha 10y ago
        Pointers could be said to be generic - int* =~ pointer<int>.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]

kasey_junk 10y ago

Yes. Same for slices & maps. Go's generic support must be built into the language.

hamandcheese 10y ago

Because the creators won't give us generics

duaneb 10y ago
...yet.
dispose13432 10y ago
I know it's a controversial point among users, but I think that if Generics were such a show stopper, Google would have implemented them. Go was invented for internal Google use, and then shared with the world, and Google is an engineering company. If engineers would have rebelled, higher management probably would have done something about it. ----- Although I don't understand why they keep fighting it. A simple style generics (Java style) shouldn't make code that ugly.
- unscaled 10y ago
  Generics are not a show stopper, since they already exist (built-in support) for everything the language creators care about. Whether or not they are a show stopper for the users - well, that depends on your use case and preferences. Since show stoppers are a subjective thing. Objectively you could implement everything in Assembly or even Machine code, and people used to write rather complex programs this way. I personally know there are a lot of types of systems I would never implement in Go if given the choice, because it would be too bothersome, and I don't like RSI. YMMV.
- catnaroek 10y ago
  Parametric polymorphism alone is a simple yet very powerful feature, but this assessment changes drastically as soon as subtyping (which both Go and Java have) enters the picture. The combination of parametric polymorphism and subtyping creates the pesky issue of determining whether Foo<T> should be a subtype of Bar<U>. Java-style generics are a lot of things (notably “bolted on”), but “simple” certainly isn't one of them. Wildcards are complex. F-bounded polymorphism is complex. Non-denotable types are complex.
  - pcwalton 10y ago
    Go doesn't have subtyping. It has coercions, which are not the same thing, and they do not lead to issues around variance. Variance is straightforward anyway. A lot of things in Go, like the semantics of "nil" and zero values, are more complex than variance. And, as a designer, if you're worried about the complexity, just make all type parameters invariant, like C++ does. It's a bad excuse to not have generics at all. Rust works exactly the same way as Go (coercions, no subtyping), except that there is subtyping in Rust via the region system. But Go doesn't have that. No region system, no subtyping.
    - catnaroek 10y ago
      What distinction between coercion and subtyping are you making? Aren't Go structs subtypes of every interface they conform to? And I don't think making all type parameters invariant eliminates any complexity. It just pushes it onto the user.
      - burntsushi 10y ago
        It would be the other way around. It is intuitive to say that interface{} is a subtype of all other types, but it is easy to show a contradiction. Assume that interface{} is a subtype of int, which means interface{} can be used in place of int in any type. So define a function with type func(xs []int). If you pass a []interface{} to this function you will get a type error. More concretely, []int and []interface{} have different in memory representations.
- closeparen 10y ago
  Do we know that Google actually uses Go extensively? AFAIK the Downloads web server is the only piece of Google publicly disclosed to be written in Go. IIRC most of Google is C++ and Java, which both have generics.
  - eggie5 10y ago
    Kubernetes is written in go
    - kasey_junk 10y ago
      Is kubernetes widely used at google?
      - vitus 10y ago
        In short, yes. How else would we provide scalable containerized services? Docker?? [0] [0] Don't be silly, of course we rolled our own.
      - lobster_johnson 10y ago
        Not widely, as far as I know. Google has two existing systems, Borg and Omega, whose ideas were distilled into Kubernetes. According to an answer on Quora in May [1], Kubernetes is only used for some things that run on the Google Cloud Platform. Some more background here [2]. [1] https://www.quora.com/Does-Google-use-the-Open-Source-Kubernetes-or-a-version-of-Borg-for-their-own-container-management https://www.quora.com/Does-Google-use-the-Open-Source-Kubern... [2] http://queue.acm.org/detail.cfm?id=2898444 http://queue.acm.org/detail.cfm?id=2898444
        Cyph0n 10y ago
        That's pretty disappointing honestly. So which container management platform is actually used at scale?
        lobster_johnson 10y ago
- deleted 10y ago
  [deleted]
- scottlamb 10y ago
  > Go was invented for internal Google use, and then shared with the world, and Google is an engineering company. If engineers would have rebelled, higher management probably would have done something about it. Not necessarily. Go was invented for internal Google use, but most of Google's code is still in C++ and Java. New projects are often started in C++ and Java, even, as they depend on libraries written in those languages. I think this would be true even if Go were perfect; switching languages is hard. But it means you shouldn't assume Google has solved whatever problems one would encounter while implementing Google product X in Go. Or that all Google engineers believe Go is a good language; as with any large group of programmers, there are people with opposing viewpoints about the virtues of various programming languages. Google management doesn't tend to impose top-down technical decisions such "product team X must use Go" [1] or "the Go team must add language feature X". They generally give broad direction and then trust the engineers doing the work to find the best technical approach to accomplish the task. [1] Although you generally must stay within the handful of approved languages: C++, Java, Go, JavaScript (for frontend stuff), Python (mostly for internal stuff, and getting less socially acceptable over time). One reason for this list is that when you write a Google system in a new language, you need a bunch of support from the rest of the company to do it: build infrastructure, libraries, etc.
- twic 10y ago
  > Go was invented for internal Google use Go was invented by a small group at Google with the aim of solving some of Google's problems as they saw them. It's not as if the whole of Google came together and collectively designed the language they needed. I wouldn't read too much into the fact that it happened to be invented at Google, rather than wherever else Rob Pike happened to be working at the time.
ridiculous_fish 10y ago
An alternative design that does not require generics is to make channel types implement a Channel interface, which has methods close(), len(), etc. This seems less magical, and would enable functions that act on channels as existentials. Why generic builtins instead of a Channel interface?
- shurcooL 10y ago
  To answer your question, from the Go FAQ [0]: Why is len a function and not a method? We debated this issue but decided implementing len and friends as functions was fine in practice and didn't complicate questions about the interface (in the Go type sense) of basic types. Also worth noting is that debate happened in 2009 or earlier, which is 7 years ago. After that, Go 1 has been released with its promise/guarantee of compatibility [1], so changing the language is not possible. It is what is, and significant language changes can only happen in Go 2. Until then, many, many people and companies are using Go 1 with huge success and happiness and have built great things with it. In practice, I find it works really well. [0] https://golang.org/doc/faq#methods_on_basics https://golang.org/doc/faq#methods_on_basics [1] https://golang.org/doc/go1compat https://golang.org/doc/go1compat
  - frou_dh 10y ago
    It's a bit of a mindfuck coming from mainstream OO languages that none of Go's built-in types have any methods† I guess there's a certain cleanliness whereby all methods exist on one side of the language/library dividing line. † The sole exception perhaps being "error", which is a pre-declared interface comprising 1 method. --- In a similar vein, this takes some getting used to: x.append(y) # No! append(x, y) # Probably Not! x = append(x, y) # Yes! (but this is not Lisp - despite appearances, the collection is mutable)
    - kazinator 10y ago
      If the object held in x is already mutable, why do we have to assign the returned value back to x also? Ah! Beacause it is like Lisp? (setf x (nconc x y)) I.e. the empty list cannot be mutated to non-empty, but non-empty can mutate to different non-empty. Surely, we could wrap append with a appendf (append functional), such that we can do: x = appendf(x, y); # no mutation: original x preserved Inside appendf we might have to do something gross, like duplicate the entire object, and append to the copy.
Animats 10y ago
Go has generics, or at least parameterized types. Maps and channels are generics. Go just doesn't have user defined generics.
- anonymoushn 10y ago
  So C has generics?
  - kzrdude 10y ago
    Why?
    - zielmicha 10y ago
      Pointers could be said to be generic - int* =~ pointer<int>.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]