4 ms·

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".