Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Go Replaces Interface{} with 'Any'

github.com

Post reply on HN
Print view View original

441–450 of 481 posts

Re: Go Replaces Interface{} with 'Any'

#441

Post by zemo »

masklinn wrote: post #321
zemo wrote: post #183

Earlier quoted context omitted.

the fact that the set of types that can satisfy an interface is open is the source of their power. "closed interfaces" are broadly an antipattern in Go.

> "closed interfaces" are broadly an antipattern in Go. That is complete nonsense. The ability to create an open set of types is powerful, so is the ability to create a closed set of types, and they are not exclusive. But go currently has only one of the two, which significantly limits its expressivity and type safety.

you can make an exported interface with an unexported method in it and voila, nobody else can implement it. That’s just broadly not that useful so it doesn’t come up a lot.

Re: Go Replaces Interface{} with 'Any'

#442

Post by masklinn »

zemo wrote: post #441
masklinn wrote: post #321

Earlier quoted context omitted.

> "closed interfaces" are broadly an antipattern in Go. That is complete nonsense. The ability to create an open set of types is powerful, so is the ability to create a closed set of types, and they are not exclusive. But go currently has only one of the two, which significantly limits its expressivity and type safety.

you can make an exported interface with an unexported method in it and voila, nobody else can implement it. That’s just broadly not that useful so it doesn’t come up a lot.

Congratulation on getting within inches of the point yet still completely whiffing. But i guess that’s the blub paradox for you.

Re: Go Replaces Interface{} with 'Any'

#443

Post by eru »

DarylZero wrote: post #326
eru wrote: post #301

Earlier quoted context omitted.

It sucks when you have to use it for everything, but it's a useful enough technique that most Haskell datatypes come with functions that provide exactly this conversion to church encoding. See eg 'maybe' ( https://www.stackage.org/haddock/lts-18.18/base-4.14.3.0/Pre... on stackage) or foldr for lists. 'foldr' is interesting, because it encapsulates a recursive pattern matching on lists. For the non-recursive version,…

It's probably actually better than pattern matching when there are only two, as in those cases. But even at three, it becomes a mess. And more than three? Yuck.

If your language does currying similar to Haskell, and there's a good order to your constructors / arguments, even with three or more there might be some benefits with partial application.

Re: Go Replaces Interface{} with 'Any'

#444

Post by eru »

Intermernet wrote: post #397
eru wrote: post #293

Earlier quoted context omitted.

Yes, but without generics it's hard to do much useful with lambdas in your statically typed language. You can't even write a filter or map function. And eg Go's old workaround for polymorphic sorting functions was just atrocious: it was rather convoluted, and only really worked at all for in-place sorting.

"without generics it's hard to do much useful with lambdas in your statically typed language" I challenge you to read the source for the Go standard library and maintain that position. Lambdas are orthogonal to generics in pretty much every aspect. You need to stop thinking in terms of "filter or map". Programming languages that didn't include these idioms existed long before Go, and will exist long after Go. I welco…

Map is a pretty fundamental thing you might want to do to your data structures (and more). Look up all the places that Haskell's "Functor" pops up for example.

Filter is much more limited in where it's applicable, that's true.

In any case, I already gave another example in my comment: sorting. And sorting's API is done terribly in the Go standard libraries.

The Go standard library does a lot with callbacks; and yes, it manages to get something useful out of them via something even uglier: mutation.

Re: Go Replaces Interface{} with 'Any'

#445

Post by eru »

naikrovek wrote: post #317
eru wrote: post #264

Earlier quoted context omitted.

I have sympathy for your sentiment, but you don't have to come up with a proper definition nor get everyone to agree on that definition. The Go people can just make up reasonable version numbers without having an all encompassing theory with definitions, and they only have to convince themselves, not everyone on earth.

> The Go people can just make up reasonable version numbers without having an all encompassing theory with definitions but "breaking change" IS the criteria for reasonable version numbers that they have chosen. "breaking change" is easily tested and well defined. "big change" is as far from well defined as you can get, because "big" is unquantifiable and subject to judgement and interpretation; i.e. a poor candidate…

The Go people did something reasonable. Yes, agreed.

I'm just saying that they could have done something different, if they had wanted to, without working out a complete theory for that different thing.

Re: Go Replaces Interface{} with 'Any'

#446

Post by eru »

swagonomixxx wrote: post #278
eru wrote: post #254

Earlier quoted context omitted.

You could separate the semantic version from the PR version. The PR version doesn't even have to be numeric. You can give them proper names.

Disagree with this. Most middle managers wouldn't understand the difference. One canonical version is enough, any more and there's just confusion, not enlightenment.

Ubuntu does pretty well with their funny animal names. Nobody confuses those with the numbers.

Re: Go Replaces Interface{} with 'Any'

#447

Post by brabel »

mappu wrote: post #108
brabel wrote: post #65

Their code is full of things like: type fileOps []any // []T where T is (string | int64) Go does not have neither generics nor union types. So people have to do this kind of thing :( I feel sorry for them. Reminds of Java 4 (15 years ago or something) where code was full of this crap: List /* */ values; Map /* */ map; Some devs spent a whole week doing nothing other than removing those commented out generic type decl…

Go has had generic List and Map since before Go 1.0, though. It's really interesting you used those as your examples because that need was fully met in a type-safe way already, and other examples are actually much rarer to come by.

It's even more interesting you chose to actually comment on the particular example I gave rather than general generics for user-defined types, which is clearly what I was talking about.

Trying to counter argue against an example by using the actual example, rather than the point the example is trying to convey, is a common, but quite dishonest debate strategy.

Re: Go Replaces Interface{} with 'Any'

#448

Post by zemo »

masklinn wrote: post #442
zemo wrote: post #441

Earlier quoted context omitted.

you can make an exported interface with an unexported method in it and voila, nobody else can implement it. That’s just broadly not that useful so it doesn’t come up a lot.

Congratulation on getting within inches of the point yet still completely whiffing. But i guess that’s the blub paradox for you.

lol the arrogance. Hilarious.

there are tools to do this, they’re not widely used because it doesn’t fit Go well. You’re trying too hard to write Go in the style of another language.

If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong. https://github.com/nishanths/exhaustive

here, have fun. You’re gonna write some tests, make new types to satisfy interfaces for testing, and then wind up with branches for your test paths in your live code, but go for it, I guess. You know everything! I am but a simple blubbite, too dim, too dim to get it.

Re: Go Replaces Interface{} with 'Any'

#449

Post by randomswede »

stormbrew wrote: post #205
philwelch wrote: post #7

Earlier quoted context omitted.

In semantic versioning, going from 1.X to 2.X is only indicated when there are incompatible API changes. Adding generics doesn’t break compatibility with preexisting Go code, so it’s unnecessary to increment the major version.

I feel like this is perhaps a bit of a gap in semver tbh. Sometimes a purely additive change can be quite major, in the sense that it shifts the thing in such a fundamental way that you are unlikely to try to interoperate between before and after, and are likely to run into trouble if you do. Basically, if 1.18 code is extremely unlikely to work against a 1.17 compiler, because a new (technically additive) feature is…

Go code that requires language (or stdlib) features first present in Go v1.n will not compile with any version of Go 1.m, m But, the backwards compatibility guarantee is that code that worked with Go v 1.n will work with Go v 1.j, for j >= n.

Next para is based on my recollection of the discussion around generics.

Specifically for generics, any code that doesn't use generics is untouched by the presence of generics elsewhere. Code that is, in and of itself, not generic will, in most cases, being able to call functions that are declared generic without extra hassle (there are most probably a few cases where a type annotation on the function using generics would be required). Code using generic data types probably needs to type-annotate, but there may be cases where it's not necessary.

Re: Go Replaces Interface{} with 'Any'

#450

Post by zemo »

zemo wrote: post #448
masklinn wrote: post #442

Earlier quoted context omitted.

Congratulation on getting within inches of the point yet still completely whiffing. But i guess that’s the blub paradox for you.

lol the arrogance. Hilarious. there are tools to do this, they’re not widely used because it doesn’t fit Go well. You’re trying too hard to write Go in the style of another language. If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong. https://github.com/nishanths/exhaustive here, have fun. You’re gonna write some tests, make new types to satisfy interfaces fo…

(this is the one I meant: https://github.com/BurntSushi/go-sumtype)
Post reply on HN