2 ms·
I was talking about a Value type being a sum type. Your widget type shouldn't be a sum type at all. For your new widget, you define an interface and you call a
by jerf 5y ago
I was talking about a Value type being a sum type. Your widget type shouldn't be a sum type at all.
For your new widget, you define an interface and you call a method. You do get full compiler support for ensuring that the method exists because if you try to pass the new widget type in to something that defines the interface, and it does not implement the interface, it is a compile-time error.
This is absolutely unidiomatic. You pay for implementing a foreign paradigm into Go code, then you pay for that foreign paradigm not doing the task you're asking it to do very well, where the native paradigm does it smoothly and correctly. This is doubly-non-idiomatic code; it's non-idiomatic Go and it's non-idiomatic FP!
- woah 5y agoSorry, but interfaces are not a replacement for sum types. Trying to shoehorn every situation where you might want to deal with multiple different types of things into figuring out what common interface they could implement is a pretty terrible pattern (although interfaces are great where they are actually applicable). The Go solution of using reflection on empty interfaces and type switches when the interface pattern fails instead of sum types is a hack that forces you to throw away type safety. Go <1.18 often feels like it is an half-finished language, except there are a lot of people ready to jump down your throat about how it's actually good that it is half-finished. Real "ignorance is strength" vibes. And I'm someone who writes Go every day.