Sounds to me like a job for a DSL that compiles down to Golang for the final output. That way, the repeated code only exists in the Golang output and not in the code that humans actually write.
more specifically, fairly basic operations on a list of data does not seem like it should call for the complexity of a DSL. IMO unless you need to do this quite a bit on random datatypes, copy & paste would probably be the better alternative. Unless you're referring to a DSL that looks exactly like Golang but with generics & monomorphism.... in which case ok I guess
https://blog.golang.org/generate
Now I'm wondering if you joke was not actually a joke.
For example Borland's BIDS 1.0 in Borland C++ for MS-DOS, it was based on the C pre-processor, as you would define a set of macros and then include the desired type, something like
#define LIST_T int
#include <bids/list.h>
#define LIST_T float
#include <bids/list.h>
To be fair, Go generics seem to be finally on their way to be adopted into the language.
https://go.googlesource.com/proposal/+/refs/heads/master/des...
https://github.com/vasilevp/aboriginal
There is no engineering challenge that can't be overcome by ingenious thought!
So, you mean it's the job for generics. Which is a DSL for, well, generic types that compiles to final output. That way, the repeated code doesn't even exist, especially not in the code that humans actually write.
Like, ask any python dev what dependency management is like. That's what iteration gets you. Take your time and you get in a much better shape.
This is stockholm syndrome.
You might find that to be a terrible idea, but others ostensibly think differently (Go is quite popular)
Personally, I prefer more advanced type systems. But I understand Go can be a good choice in other situations.
Well sure, but inheritance and enterprise-style Java were all the rage in the 90s, but they largely haven't stood the test of time. I rather suspect Go will be similar. It has some good ideas, and it's compiler toolchain is top-quality. But I'd be willing to bet that the languages we're using in 20 years time look a lot more like Rust/Swift/Kotlin and TypeScript/Julia than Go.
Java was released in 1996, and only got enterprise-style C++ adoption around 2000.
Until then, the inheritance and enterprise-style programming was done in a mix of Smalltalk, Eiffel, C++ and C based OOP.
Julia is basically Dylan/Common Lisp at its kernel, Java and C# are getting all the ML like goodies to stay relevant, see C# vs F#.
Right now, the Go spec + compiler chain are a lot simpler; adding generics would have made things a ton more complicated. Second, by first spending a lot of time perfecting the core language, understanding it, and resolving early issues, they have a much more stable base now to build generics on top of it. As the comment also implies, they take things slow and steady when it comes to Go; it's a language made to run core systems (e.g. at Google) for the next 30-50 years.