5 ms·

__For a concrete example, the fact you cannot define custom methods for external types in Go (a pre-1.0 design decision) means that you cannot write proper com

by aatd86 2mo ago

__For a concrete example, the fact you cannot define custom methods for external types in Go (a pre-1.0 design decision) means that you cannot write proper compile-time generic code to deal with some generic wrapping type (dumb example -- getting a sum of the perimeters of a generic set of shapes in an externally-defined collection type) -- you are forced to work around it with runtime type-switching. There are all sorts of arguments you can make about simplicity but this is an objective shortcoming of Go that is directly caused by generics being added to Go long post 1.0.__ I'm a bit intrigued by this: how would that work with compatibility between libraries, separate compilation and what not? My first instinct is that it would not be a good idea but I might be missing something..?

cyphar 2mo ago
In Rust this is solved by defining a local trait and methods implemented for a trait are only available if the trait is imported. This is in contrast to Go where methods are not namespaced at all. But there are almost certainly many other ways of solving the problem. I was a little surprised how often I ran into this issue when using libraries that started defining structures as generic containers.
- aatd86 2mo ago
  Yes, so that is exactly what I don't understand, that makes compilation flow sensitive in a way that Go avoids by design in order to remain fast.
  - cyphar 2mo ago
    Not really, Go already disallows import loops so even if Go did have exportable traits the compilation flow would be the same. But traits wouldn't really make sense for Go -- my point was that there is are solutions for this problem in other languages; Go's original design goals don't gel well with generics which leads to these kinds of issues. They felt generics weren't necessary so they didn't design Go with them in mind.
    - aatd86 2mo ago
      It's not much import loops rather than introducing fine-grained conditional compilation, since behavior changes depending on whether a trait is imported or not. That has an effect on incremental compilation unless I am mistaken. So even if generics were there from the 'get-go', I am not sure this exact feature would be added anyway. In fact, it is mostly contrary to Go's structural polymorphism, let alone parametric polymorphism. Typically what you want would be defined as a function, a specific wrapper type... If it is not already a common method of each shape. So far, I don't feel like the design of Go's generics suffers from any real issue. The implementation is not 100 percent done yet. But the plan looks sound to me.

by aatd86 2mo ago

cyphar 2mo ago

In Rust this is solved by defining a local trait and methods implemented for a trait are only available if the trait is imported. This is in contrast to Go where methods are not namespaced at all. But there are almost certainly many other ways of solving the problem. I was a little surprised how often I ran into this issue when using libraries that started defining structures as generic containers.

aatd86 2mo ago
Yes, so that is exactly what I don't understand, that makes compilation flow sensitive in a way that Go avoids by design in order to remain fast.
- cyphar 2mo ago
  Not really, Go already disallows import loops so even if Go did have exportable traits the compilation flow would be the same. But traits wouldn't really make sense for Go -- my point was that there is are solutions for this problem in other languages; Go's original design goals don't gel well with generics which leads to these kinds of issues. They felt generics weren't necessary so they didn't design Go with them in mind.
  - aatd86 2mo ago
    It's not much import loops rather than introducing fine-grained conditional compilation, since behavior changes depending on whether a trait is imported or not. That has an effect on incremental compilation unless I am mistaken. So even if generics were there from the 'get-go', I am not sure this exact feature would be added anyway. In fact, it is mostly contrary to Go's structural polymorphism, let alone parametric polymorphism. Typically what you want would be defined as a function, a specific wrapper type... If it is not already a common method of each shape. So far, I don't feel like the design of Go's generics suffers from any real issue. The implementation is not 100 percent done yet. But the plan looks sound to me.