Hacker News Reader

Comment by moth-fuzz | Hacker News Reader

I'm not sure I like this change. I liked interface{} since it just works out naturally from Go's relatively simple type system, and anyone could come to the conclusion without actually being told "use interface{} to represent any possible value" just by having an understanding of that type system. Adding what is simply a type alias, multiple words for the same underlying concept, to me just feels like jargon. I admire Go for its simplicity and clarity and this change gives me anxiety that that will be obfuscated.

View on HN

I don’t think the concern is unreasonable at all but ‘any’ feels pretty solid as far as I’ve had the chance to poke around. There’s some tensions where I think ‘any’ is arguably much simpler:

The baseline is that constraints aren’t best expressed as interface literals in situ. Unlike exceptional use of ‘interface{}’, ‘any’ will be a more naturally invoked constraint.

Also, some of the uses of constraints rely on a unification involving an ‘any’ term that cancels out. Here, the use of ‘interface{}’ is not incorrect but maybe indirect.

with generics you wind up with two parameter lists, and type parameters have metatypes. All type parameters need to have a metatype, and the metatype `any` comes up a lot. Once you start using generics you'll start to feel the pain of writing `interface{}` in those signatures, especially when you are dealing with functions like this one:

    func doSomething[X interface{}, Y Fooer[interface{}]](v X, src Y) error {
    }

versus:

    func doSomething[X any, Y Fooer[any]](v X, src Y) error {
    }

the signatures can get long pretty quickly when you have more than one type parameter.

Does a personal (not language-wide)

  type any = interface{}

not work, if you felt that strongly?

That's an extra line of boilerplate. If someone for some reason wants uglier and longer code then can still use interface{}

I agree with you right now, but I wonder if I will change my mind after having had some experience using the new generics. Maybe it will feel more natural then?

Isn't Any essentially:

type Any interface{}

It's a type alias so it's

    type any = interface{}

That means they're interchangeable compared to defining a new type.

Close, it's:

    type Any = interface{}

That is, it's an alias and casting is not necessary.

I'm pretty sure it's an alias, so: `type any = interface{}`.

`type any interface{}` would declare a new type, while an alias is exactly another name for the same type.

Reply on news.ycombinator.com