You’ve missed the point. There are trade-offs that you are ignoring. There is no hard science that proves either of our opinions are right. I believe diversity is the better path in the face of such uncertainty, I don’t understand why you are against diversity here, and you continue to not directly answer that question.
“ If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere.”
This shows a profound lack of understanding of software development at scale.
Re:Go 1.18
by pie_flavor on Thursday March 17, 2022 @12:28PM
(#30712961)
Of course I'm not directly answering a polemic gotcha. If I work in Go, and I have a pain point in Go, and I want that pain point to be addressed, that's not being 'against diversity' or being 'for diversity'. It is being against wasting lots of time for nothing. Why are you against productivity? You continue to not directly answer that question.
Unlike you, I’ve answered your question many times. You are only looking at the benefit for a narrow use case without accounting for its holistic costs. We have a difference of opinion about those costs, and there is no hard science that can prove either of us right. I have acknowledged your point of view, and the possibility that it could be right. You have not reciprocated in any way, or even acknowledge that you understand the point I’m making.
Re:Go 1.18
by pie_flavor on Thursday March 17, 2022 @08:52PM
(#30717510)
Diversity doesn't have anything to do with holistic costs. You shift between whether you're talking about holistic costs and whether you're talking about diversity depending on which part of the point you're making.
Can't you and yours just freeze at go 1.7? That way, you get your diversity. Pretend every code base that's using go 1.8 is using java or something. A lot of us who write go everyday think generics aren't complicated and are tired or repeating ourselves.
If your code did not use generics, it can continue to not use generics. If you did not interact with any libraries whose need for generics was apparent, you can continue to do that too and the libraries you were using aren't going anywhere.
But just because you don't interact with a problem doesn't mean it doesn't exist, and the problem has historically been solved with dynamic downcasting, code generation, or copy-pasting, all of which result in codebases far harder to read and understand than most other languages. For these problems, you are not trading off generic code vs simple code, you are trading off generic code vs incomprehensible code. It is great that you have never needed a tree-map instead of a hash-map, but many have.
Go's simplicity is in many ways it being the spiritual successor to C, and even C has generics nowadays because they are an enormous value add.