Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I’d kill for union types as well.

> … and pattern matching. Maybe just some extensions for `switch`.

Go has type switches which are… ok. If it were possible to “close up” interfaces and type switches took that in account (match completeness) you’d be done about done, you would not have the structural / patterned unpacking but that’s probably less of a concern.



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.


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.


> lol the arrogance. Hilarious.

Yes, the hilarious arrogance of… taking in account useful things that work?

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

Literally the exact same statement could be made about generics.

> If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong.

Wonderfully missing the point again.

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

Oh boy, ain’t that one for Principal.

> You know everything!

You’re the person declaring sum types useless in the face of decades of evidence and completely incapable of handling the idea of disagreement.

> I am but a simple blubbite, too dim, too dim to get it.

I see you don’t understand the blub paradox either.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: