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
This is how C++ compilers used to work before templates came into the picture.
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>
and so on, however when BIDS 2.0 was released, there was already primitive support for the ongoing ISO discussions and it was rewritten to use templates.
To be fair, Go generics seem to be finally on their way to be adopted into the language.
As heavy critic, but also fan, I have been following up on it, and the last update on the document is from September, so I am positive they might make it, it just appears the proper implementation still has some engineering challenges.
> Sounds to me like a job for a DSL that compiles down to Golang for the final output.
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.
"Good" is meaningless – there is no absolute measure of the relative value of one programming language over another. C is not "better" than Python, or vice versa, just different tradeoffs for different problems and programming styles. The same is for Go.
I think there is some measure of value to not having to use a whole different language to generate go because it's incapable of making maintainable code without it.
Part of Go’s tradeoff is managing that extra effort (or delay in waiting for the features to hit the main branch) in return for an extremely stable, simple language.
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.
Kind of, but C and Python have undergone many iterations to try to become as good as they can be, while Go has lagged behind and almost prides itself on how uncomplex it is which is unfortunate only because people crave for it to be more complex. With languages like C and Python, the complexity and capability is there; it’s on you to decide when to use it. With Golang, you are just SOL.
The thing is, do you want so many iterations to get something close to being good. Or do you want people to work with the community and decide together what a feature should look like and then get it in a good shape at day 1.
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.
Thing is, I’m not convinced Go is actually “taking their time,” it’s just intentionally crap and there won’t be any significant improvements. Generics have been “coming” since the language became popular ~10 years ago.
Because generics is a nontrivial problem to solve in languages and compilers; a really great comment that I bookmarked is here: https://news.ycombinator.com/item?id=9622417. I read elsewhere (can't find it now) just how much lines of code and language spec is dedicated to generics in Java.
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.
All I can say to that is: Taking Java and C++ to be generics as god intended is not a particularly good thing to plan around. D's generics are concise, strict, relatively simple, and mostly understandable by mere mortals (in the compiler) - this is a totally solved problem for a language like D, if Go can't do it then it's their own fault.
