Always good to run into programmers who want you to know they know what you should want.https://twitter.com/wycats/status/1036672033503862785 …
For the second, do you mean something like this argument:https://medium.com/capital-one-developers/closures-are-the-generics-for-go-cb32021fb5b5 …
-
-
I have several problems with that article but it does address using closures. There are other ways to use closures as various kinds of "glue" that have nothing to do with generics. Frankly the Java example was how to do closures, before Java had closures. Today I'd use closures.
-
The worse problem in that article is often repeated: "In Go, you have two choices — either you can write the data structure over and over for each type that you need (or use a code generator to save some typing) or you need to define your data type in terms of interface{}"
-
This is a problem because it ignores the best aspect of Go's interfaces. Way too often people use "any", ie interface{} instead of defining an interface with behavior. The bulk of the problem in that article is solvable using objects, ie interfaces with appropriate behavior.
-
In conjunction with interfaces, the ability to define a new type in order to ascribe new behavior to some other type is a very powerful way to extend the applicability of values, structs, etc
-
Nearly every article on Go I've read misses this mark by a long shot, including this one. The sad, slow decline of OOP from mainstream programming.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.