7 ms·

No type definitions for methods :(

by eweise 5y ago

deleted 5y ago
[deleted]
pie_flavor 5y ago
Methods exist to implement interfaces. Interfaces cannot have generic methods because those would need to be instantiated at runtime, which would require runtime codegen.
- sciolizer 5y ago
  Why do you need runtime codegen? What exactly needs to be "instantiated"? Ultimately the runtime representation of a type parameter comes down to sizes and offsets. Why not have the caller pass those values into the generic method?
  - smasher164 5y ago
    See here: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods https://go.googlesource.com/proposal/+/refs/heads/master/des...
    - hombre_fatal 5y ago
      Nice find.
    - adrusi 5y ago
      Ugh yeah. The ability to check at runtime if a value satisfies an interface, combined with structural typing... So now the static expressivity of the type system is compromised in the name of runtime introspection. Reminiscent of how when Java added generics, runtime introspection ended up totally blind to them due to erasure. This seems like the result of not taking care to account for the possible future addition of generics when originally designing the language — it was always well understood that they’d be a likely later addition to the language. The ability to check if a value satisfies an interface at runtime doesn’t seem all that critical, although I could be missing something, I’m not a regular user of the language.
      - morelisp 5y ago
        It's not as common as unwrapping to concrete types, but still frequently used. One place it's absolutely critical, and certainly the most common by number-of-calls even if people don't think about it, is `fmt` functions that check to see if the type implements `String() string`. An idiom found in many data-shuffling libraries is to accept a small interface like `io.Writer`, but have fast-paths if the type also implements other methods. E.g. https://cs.opensource.google/go/go/+/refs/tags/go1.18:src/io/io.go;l=402 https://cs.opensource.google/go/go/+/refs/tags/go1.18:src/io... It's a little annoying but I don't think it's as bad as Java's erasure. We're still very early in idiomatic Go-with-generics so maybe we'll see a huge impact from this limitation later, but most times I see people wanting generic method parameters, they've got a design in mind which would be horribly inefficient even if it was valid. If you are going to box everything and generate lots of garbage, you might as well write Java to begin with.
        adrusi 5y ago
        For the case of coercing a specifically a function argument to a different interface, there is a solution that isn't stupidly inefficient, but it's impossible to support for the general case of coercing any interface value to a different interface. I expect 90% of the time a function coerces and interface value to a different interface, that value is one of its arguments, but to support that case for generic interfaces but not the other 10% would be a really ugly design. I think you'd also have issues with treating functions that coerce their arguments to generic interfaces as first class functions. package p1 type S struct{} func (S) Identity[T any](v T) T { return v } package p2 type HasIdentity[T any] interface { Identity(T) T } package p3 import "p2" // Because parameter v might be (and in this case is) coerced into // p2.HasIdentity[int], this function gets a type annotation in the compiler // output indicating that callers should pass a p2.HasIdentity[int] interface // reference for v if it exists, or nil if it doesn't, as an additional // argument. func CheckIdentity(v interface{}) { if vi, ok := v.(p2.HasIdentity[int]); ok { if got := vi.Identity(0); got != 0 { panic(got) } } } package p4 import ( "p1" "p3" ) func CheckSIdentity() { p3.CheckIdentity(p1.S{}) }
azth 5y ago
Quite typical of golang pushing more complexity onto the user in order to save complexity in the compiler, then claim that golang is a "simple" language shrugs.
- zarzavat 5y ago
  While it’s fun to hate on Go and the language has indeed made some bizarre design choices, the fact that there’s even a market for Go shows that there’s some major deficiencies in other languages. If Go is really so bad, why don’t Go programmers use e.g. Rust? I’m sure they’d cite things like: - Compilation time is much faster in Go. - Complexity. Rust is a highly complex language even for me as a C++ programmer. For those who are new to compiled languages they are certainly going to choose Go over Rust - GC definitely has development time benefits over a borrow checker if you can afford the extra CPU headroom and memory usage - Go’s concurrency model is more appealing to many people The real question is, why is there not a “Go but designed by sane people” language?
  - azth 5y ago
    golang doesn't really compete with rust, but it's more like a faster python/ruby/js. You can see this by the companies that have moved over from those languages to golang. Hype definitely plays a role, but also the perception that it's quick to pick up, and does decently well when it comes to performance. > The real question is, why is there not a “Go but designed by sane people” language? The fact is that the JVM and .NET platforms would almost surely do better for anything that golang is considered for, but there's a lot of hype and companies want to attract programmrs.
  - kaba0 5y ago
    The real question is why not just use Java, C#, D, Haskell, Js or the myriad other managed languages? Rust is complex due to the inherent complexity of being a low-level language.
- philosopher1234 5y ago
  Let’s not be so simple minded. Users bear some of the cost of complex compilers, too. And complex languages, even if they make writing some code simpler, ALWAYS have a cost. It’s a balance, there’s not an obvious right answer.
morelisp 5y ago
As someone working to see where generics would benefit my actually-existing go projects and not starting with the assumption that something like lodash would be good, this has not been a problem at all. "No way to require pointer methods" has been much more frustrating to work around. Even the part that works ("Pointer method example") sucks right now because type-type inference was disabled shortly before the 1.18 release pending some bugs. Hopefully once the basic ergonomics are back this can be reconsidered.

No type definitions for methods :(

by eweise 5y ago

No type definitions for methods :(

deleted 5y ago

[deleted]

pie_flavor 5y ago

Methods exist to implement interfaces. Interfaces cannot have generic methods because those would need to be instantiated at runtime, which would require runtime codegen.

sciolizer 5y ago
Why do you need runtime codegen? What exactly needs to be "instantiated"? Ultimately the runtime representation of a type parameter comes down to sizes and offsets. Why not have the caller pass those values into the generic method?
- smasher164 5y ago
  See here: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods https://go.googlesource.com/proposal/+/refs/heads/master/des...
  - hombre_fatal 5y ago
    Nice find.
  - adrusi 5y ago
    Ugh yeah. The ability to check at runtime if a value satisfies an interface, combined with structural typing... So now the static expressivity of the type system is compromised in the name of runtime introspection. Reminiscent of how when Java added generics, runtime introspection ended up totally blind to them due to erasure. This seems like the result of not taking care to account for the possible future addition of generics when originally designing the language — it was always well understood that they’d be a likely later addition to the language. The ability to check if a value satisfies an interface at runtime doesn’t seem all that critical, although I could be missing something, I’m not a regular user of the language.
    - morelisp 5y ago
      It's not as common as unwrapping to concrete types, but still frequently used. One place it's absolutely critical, and certainly the most common by number-of-calls even if people don't think about it, is `fmt` functions that check to see if the type implements `String() string`. An idiom found in many data-shuffling libraries is to accept a small interface like `io.Writer`, but have fast-paths if the type also implements other methods. E.g. https://cs.opensource.google/go/go/+/refs/tags/go1.18:src/io/io.go;l=402 https://cs.opensource.google/go/go/+/refs/tags/go1.18:src/io... It's a little annoying but I don't think it's as bad as Java's erasure. We're still very early in idiomatic Go-with-generics so maybe we'll see a huge impact from this limitation later, but most times I see people wanting generic method parameters, they've got a design in mind which would be horribly inefficient even if it was valid. If you are going to box everything and generate lots of garbage, you might as well write Java to begin with.
      - adrusi 5y ago
        For the case of coercing a specifically a function argument to a different interface, there is a solution that isn't stupidly inefficient, but it's impossible to support for the general case of coercing any interface value to a different interface. I expect 90% of the time a function coerces and interface value to a different interface, that value is one of its arguments, but to support that case for generic interfaces but not the other 10% would be a really ugly design. I think you'd also have issues with treating functions that coerce their arguments to generic interfaces as first class functions. package p1 type S struct{} func (S) Identity[T any](v T) T { return v } package p2 type HasIdentity[T any] interface { Identity(T) T } package p3 import "p2" // Because parameter v might be (and in this case is) coerced into // p2.HasIdentity[int], this function gets a type annotation in the compiler // output indicating that callers should pass a p2.HasIdentity[int] interface // reference for v if it exists, or nil if it doesn't, as an additional // argument. func CheckIdentity(v interface{}) { if vi, ok := v.(p2.HasIdentity[int]); ok { if got := vi.Identity(0); got != 0 { panic(got) } } } package p4 import ( "p1" "p3" ) func CheckSIdentity() { p3.CheckIdentity(p1.S{}) }

azth 5y ago

Quite typical of golang pushing more complexity onto the user in order to save complexity in the compiler, then claim that golang is a "simple" language shrugs.

zarzavat 5y ago
While it’s fun to hate on Go and the language has indeed made some bizarre design choices, the fact that there’s even a market for Go shows that there’s some major deficiencies in other languages. If Go is really so bad, why don’t Go programmers use e.g. Rust? I’m sure they’d cite things like: - Compilation time is much faster in Go. - Complexity. Rust is a highly complex language even for me as a C++ programmer. For those who are new to compiled languages they are certainly going to choose Go over Rust - GC definitely has development time benefits over a borrow checker if you can afford the extra CPU headroom and memory usage - Go’s concurrency model is more appealing to many people The real question is, why is there not a “Go but designed by sane people” language?
- azth 5y ago
  golang doesn't really compete with rust, but it's more like a faster python/ruby/js. You can see this by the companies that have moved over from those languages to golang. Hype definitely plays a role, but also the perception that it's quick to pick up, and does decently well when it comes to performance. > The real question is, why is there not a “Go but designed by sane people” language? The fact is that the JVM and .NET platforms would almost surely do better for anything that golang is considered for, but there's a lot of hype and companies want to attract programmrs.
- kaba0 5y ago
  The real question is why not just use Java, C#, D, Haskell, Js or the myriad other managed languages? Rust is complex due to the inherent complexity of being a low-level language.
philosopher1234 5y ago
Let’s not be so simple minded. Users bear some of the cost of complex compilers, too. And complex languages, even if they make writing some code simpler, ALWAYS have a cost. It’s a balance, there’s not an obvious right answer.

morelisp 5y ago

As someone working to see where generics would benefit my actually-existing go projects and not starting with the assumption that something like lodash would be good, this has not been a problem at all. "No way to require pointer methods" has been much more frustrating to work around. Even the part that works ("Pointer method example") sucks right now because type-type inference was disabled shortly before the 1.18 release pending some bugs. Hopefully once the basic ergonomics are back this can be reconsidered.