6 ms·

So wait, they're introducing magic "function" that has a variable number of generic return arguments? Huh. In Rust the try! macro makes sense because A. there's

So wait, they're introducing magic "function" that has a variable number of generic return arguments? Huh. In Rust the try! macro makes sense because A. there's a precedence of macros and B. there's a precedence of generics. But in a language with neither macros nor generics, this just seems odd. Kinda like making the Justice League movie without any of the requisite standalone movies.

kyrra 7y ago
panic() and recover() are a built-in function, so there is already some precedent for doing this.
- jerf 7y ago
  Also append(), copy(), new(), etc. Technically ("well, acksually"), Go doesn't "lack generics". It lacks user-defined generics. The language implementation has several generics in it, you just can't add your own. So if you hear "Go doesn't have generics" that can give you a slightly incorrect impression about the language itself, but of course what people do generally mean is that it lacks user-defined generics and that that is bad, so there's still certainly a valid criticism there. It just may not quite be what you thought it was.
  - aikah 7y ago
    > Technically ("well, acksually"), Go doesn't "lack generics". Yes it does, generics are types. You bet all these append(T[A],A)T[A] tricks are hard-coded in the compiler in an adhoc fashion, and not part of Go's type system.
    - AnimalMuppet 7y ago
      I don't think I'd bet that way...
      - bsaul 7y ago
        I’ve heard this « go has generic it just doesn’t let you access it » argument so many times, it would be really good if someone could actually point to the piece of compiler code that define those generic capabilities. My guess is they don’t have anything usable by the end user any way, otherwise they wouldn’t spend so much time thinking about a design for go 2. It probably means whatever is in the compiler isn’t that elegant, nor reusable.
        edflsafoiewq 7y ago
        Implementation choices are just that. Arguments about whether the language does or does not have generics should refer to properties of the language, not properties of the compiler.
        bsaul 7y ago
        The argument indeed isn’t about the language, but about the reason why the language doesn’t have generics. The fact that some predefined functions are developped using something looking like a generic type system, or not, is an interesting factor in this conversation.
      - unscaled 7y ago
        Of course it is: https://github.com/golang/go/blob/3813edf26edb78620632dc9c7d66096e5b2b5019/src/go/types/builtins.go#L77 https://github.com/golang/go/blob/3813edf26edb78620632dc9c7d...
  - munificent 7y ago
    I don't think this is a useful perspective. Every language with a static type system has some "built in generic types". Even Pascal and C have array types. So there's no point in requiring the "user-defined" qualifier. For "generics" to mean anything useful, there must be some languages that the word applies to and some that it doesn't. If you treat "user-defined" as implicit, then that works. If you don't, then it says nothing.
  - unscaled 7y ago
    The problem with built-in generics is that they are quite ad-hoc and hard to reason about. Each generic built-in function is re-implemented by hand in the compiler. If we call this type of ad-hoc implementation "generics", we're going down a very deep rabbit hole, since then almost any programming language can be said to have generics. For instance, Write[Ln] in Pascal, sizeof() in C, all array functions in Java pre-1.5. In other words, technically when people say "Language X lacks generics" they always mean "Language X lacks orthogonal, predictable, non ad-hoc, user defined generics".
kardianos 7y ago
Go already has "append". It would be similar in that sense.
- masklinn 7y ago
  append, close, len, … I guess the new bit is the variable-arity result from a function, not just a language feature (e.g. <- or range).
lmkg 7y ago
In fairness to Go, there is a precedent for built-ins to be "special" in ways like this. So e.g. while there are no user-defined generic data types, the built-in collection types like array are generic. The Zen of Rust is very much in the direction that standard operators shouldn't be more "special" than necessary, and a lot of fundamentals become "library-able" or at least library-extensible. Go simply doesn't take this approach. It's a more opinionated language, and it some cases that means you get the tool it makes for you, rather than getting to craft your own tool for yourself.
jjoonathan 7y ago
Isn't "generics for me but not for thee" already a core part of the Go philosophy?
- aikah 7y ago
  No, you are trying to justify odd builtin functions choice in retrospect. Nobody has ever said that Go "secret generics" are a core part of the Go philosophy but you. The reason they exist is because Go language designers could not do without them. The same people that have claimed for years that Go didn't need generics.
  - icholy 7y ago
    > The same people that have claimed for years that Go didn't need generics. Considering all the successful software that's been written in Go, they weren't exactly wrong.
    - Someone 7y ago
      I don’t think that’s a valid argument. Firstly, successful software has been written in languages that we would call atrocious nowadays. Also, even if go were better than all other languages, it still might not be perfect. Let’s say there are 10 ‘objectively good’ programming language features. If most languages have 7, but go has 8, you still can complain about wanting the two other ones.
    - aikah 7y ago
      > Considering all the successful software that's been written in Go, they weren't exactly wrong. Considering all the successful software written in PHP...? Or Javascript...? Java...? Your argument absolutely has nothing to do with my point.
      - icholy 7y ago
        I think you're confusing "want" with "need"
    - 7y ago
deleted 7y ago
[deleted]

kyrra 7y ago

panic() and recover() are a built-in function, so there is already some precedent for doing this.

jerf 7y ago
Also append(), copy(), new(), etc. Technically ("well, acksually"), Go doesn't "lack generics". It lacks user-defined generics. The language implementation has several generics in it, you just can't add your own. So if you hear "Go doesn't have generics" that can give you a slightly incorrect impression about the language itself, but of course what people do generally mean is that it lacks user-defined generics and that that is bad, so there's still certainly a valid criticism there. It just may not quite be what you thought it was.
- aikah 7y ago
  > Technically ("well, acksually"), Go doesn't "lack generics". Yes it does, generics are types. You bet all these append(T[A],A)T[A] tricks are hard-coded in the compiler in an adhoc fashion, and not part of Go's type system.
  - AnimalMuppet 7y ago
    I don't think I'd bet that way...
    - bsaul 7y ago
      I’ve heard this « go has generic it just doesn’t let you access it » argument so many times, it would be really good if someone could actually point to the piece of compiler code that define those generic capabilities. My guess is they don’t have anything usable by the end user any way, otherwise they wouldn’t spend so much time thinking about a design for go 2. It probably means whatever is in the compiler isn’t that elegant, nor reusable.
      - edflsafoiewq 7y ago
        Implementation choices are just that. Arguments about whether the language does or does not have generics should refer to properties of the language, not properties of the compiler.
        bsaul 7y ago
        The argument indeed isn’t about the language, but about the reason why the language doesn’t have generics. The fact that some predefined functions are developped using something looking like a generic type system, or not, is an interesting factor in this conversation.
    - unscaled 7y ago
      Of course it is: https://github.com/golang/go/blob/3813edf26edb78620632dc9c7d66096e5b2b5019/src/go/types/builtins.go#L77 https://github.com/golang/go/blob/3813edf26edb78620632dc9c7d...
- munificent 7y ago
  I don't think this is a useful perspective. Every language with a static type system has some "built in generic types". Even Pascal and C have array types. So there's no point in requiring the "user-defined" qualifier. For "generics" to mean anything useful, there must be some languages that the word applies to and some that it doesn't. If you treat "user-defined" as implicit, then that works. If you don't, then it says nothing.
- unscaled 7y ago
  The problem with built-in generics is that they are quite ad-hoc and hard to reason about. Each generic built-in function is re-implemented by hand in the compiler. If we call this type of ad-hoc implementation "generics", we're going down a very deep rabbit hole, since then almost any programming language can be said to have generics. For instance, Write[Ln] in Pascal, sizeof() in C, all array functions in Java pre-1.5. In other words, technically when people say "Language X lacks generics" they always mean "Language X lacks orthogonal, predictable, non ad-hoc, user defined generics".

kardianos 7y ago

Go already has "append". It would be similar in that sense.

masklinn 7y ago
append, close, len, … I guess the new bit is the variable-arity result from a function, not just a language feature (e.g. <- or range).

lmkg 7y ago

In fairness to Go, there is a precedent for built-ins to be "special" in ways like this. So e.g. while there are no user-defined generic data types, the built-in collection types like array are generic. The Zen of Rust is very much in the direction that standard operators shouldn't be more "special" than necessary, and a lot of fundamentals become "library-able" or at least library-extensible. Go simply doesn't take this approach. It's a more opinionated language, and it some cases that means you get the tool it makes for you, rather than getting to craft your own tool for yourself.

jjoonathan 7y ago

Isn't "generics for me but not for thee" already a core part of the Go philosophy?

aikah 7y ago
No, you are trying to justify odd builtin functions choice in retrospect. Nobody has ever said that Go "secret generics" are a core part of the Go philosophy but you. The reason they exist is because Go language designers could not do without them. The same people that have claimed for years that Go didn't need generics.
- icholy 7y ago
  > The same people that have claimed for years that Go didn't need generics. Considering all the successful software that's been written in Go, they weren't exactly wrong.
  - Someone 7y ago
    I don’t think that’s a valid argument. Firstly, successful software has been written in languages that we would call atrocious nowadays. Also, even if go were better than all other languages, it still might not be perfect. Let’s say there are 10 ‘objectively good’ programming language features. If most languages have 7, but go has 8, you still can complain about wanting the two other ones.
  - aikah 7y ago
    > Considering all the successful software that's been written in Go, they weren't exactly wrong. Considering all the successful software written in PHP...? Or Javascript...? Java...? Your argument absolutely has nothing to do with my point.
    - icholy 7y ago
      I think you're confusing "want" with "need"
  - 7y ago

deleted 7y ago

[deleted]