Given the wait and see approach taken by Go maintainers on generics/templates I think there may be an opportunity for a template based pre-processor scheme (not using go generate since that works on go files). This approach would be the C++ approach - i.e., templates not generics.
The template could be in, say for Vectors, a Vector.got file.
In your go code (also a .got file - say my.got for example) you reference Vector<SomeType>. Some build system+pre-processor parses .got files and creates a Vector_SomeType.go file. A corresponding my.go file is also generated from my.got with all template references flattened to real types.
All *.go files are compiled using the regular go build chain to create the final application. Any missing types would be identified by the go compiler.
make could be used to drive the process, but the got2go translator application is the missing piece. Is it better than generics inside the language - no. It is very loose in terms of type safety as we are just performing text substitutions but it could save a lot of typing. We could also come to rely on a semi official/community approved repository of core collection .got files. The C++ STL implementations may serve as an inspiration for the API of core template code.
This is what Borland C++ had in the mid-90s before they added support for template on their MS-DOS compiler.
Way back when STL had just been announced as being integrated into the C++ standardisation effort and C++ compiler vendors were using preprocessor tricks to generate type specific generic data structures and algorithms.
The template could be in, say for Vectors, a Vector.got file. In your go code (also a .got file - say my.got for example) you reference Vector<SomeType>. Some build system+pre-processor parses .got files and creates a Vector_SomeType.go file. A corresponding my.go file is also generated from my.got with all template references flattened to real types.
All *.go files are compiled using the regular go build chain to create the final application. Any missing types would be identified by the go compiler.
make could be used to drive the process, but the got2go translator application is the missing piece. Is it better than generics inside the language - no. It is very loose in terms of type safety as we are just performing text substitutions but it could save a lot of typing. We could also come to rely on a semi official/community approved repository of core collection .got files. The C++ STL implementations may serve as an inspiration for the API of core template code.