Thanks for the link. Interesting to see this take on generics in go - I like that they've come up with a concrete example of how it could work (with code generation). It'll be interesting to see if the Go team come up with something like this for Go 2 - if they did it'd probably affect quite a few different areas of the stdlib and standard go programs. I have mixed feelings about it - on the one hand it'd be handy for certain uses which at present are a little clunky and require generated code, but on the other hand it could end up moving the language in a very different (and more complex) direction, and you wouldn't be able to avoid it because lots of libraries would start using generics everywhere.
It would be quite interesting it it could be kept like this: as a separate (but Go-compatible) that can be compiled to concrete Go code behind the scenes. Not sure about the limitations about that approach though ... perhaps not everything can be generated up-front etc.
Don't miss the playground: https://play.folang.org
Thanks for the link. Interesting to see this take on generics in go - I like that they've come up with a concrete example of how it could work (with code generation). It'll be interesting to see if the Go team come up with something like this for Go 2 - if they did it'd probably affect quite a few different areas of the stdlib and standard go programs. I have mixed feelings about it - on the one hand it'd be handy for certain uses which at present are a little clunky and require generated code, but on the other hand it could end up moving the language in a very different (and more complex) direction, and you wouldn't be able to avoid it because lots of libraries would start using generics everywhere.
It would be quite interesting it it could be kept like this: as a separate (but Go-compatible) that can be compiled to concrete Go code behind the scenes. Not sure about the limitations about that approach though ... perhaps not everything can be generated up-front etc.