3 ms·
These two statements are arguments for different discussions: > I don't see how generics are needed to deal with "complex business logic". Here, we're talking
by golergka 9y ago
These two statements are arguments for different discussions:
> I don't see how generics are needed to deal with "complex business logic".
Here, we're talking about what user (developer who chooses between Go and Java) needs or wants. User doesn't care about costs behind the product.
However, instead of proving this statement, you jump to a different perspective whatsoever:
> But, as they have clearly laid out, this is not a trivial undertaking. There hasn't yet been an implementation concept presented, which fits into the Go framework with its design goals.
And here you're estimating things from the cost perspective; and it quite logically follows that it's not rational for Go developers to dive into generics at the moment. Just keep it mind that this decision means that Go stays unappealing to users like me.
- _ph_ 9y agoNo, I am not talking about costs at all. First of all, I don't see how complex business logic requires generics. I have written complex business applications and not required them. I really have no idea why you would "need" them. And also for the Go developers, it is not about "cost". They have no idea how they could implement generics without fundamentally changing the Go language to something different than what it was about before. They are working on concepts, but nothing resulted what would be a candidate for implementation.
- willtim 9y agoThis boils down to how much one values static types and code reuse. If you do not have Generics (a.k.a. parametric polymorphism) then you are forced to make a choice between type safety and code reuse. You cannot have them both.