I have not used Go generics, but it's viability as a business logic language would depend on that.
Generic programming is a perfectly valid style, but are you saying it's essential to implement business logic?
Because, like, the last 3 languages that got adopted as the default business logic language didn't have them (Java pre 1.5, C, and Cobol).
I mean, don't get me wrong. It's quite useful once in a while, especially when working with containers, but I don't think of it as essential.
But I'm fine with it as long as people don't overdo it.
This thread was in the context of go generics, which generally means go 1.18, when user defined generics were added to the language. Go always had support for a minimal number of containers, I've never rolled my own when working in the language.
Go had special compiler support for slices, maps, and channels before then, and they got used as the default containers for everything.
Using those was annoying when you needed to do the same thing to, say, a slice of strings and a slice of ints, but if you aren't using a generic heavy style, it actually comes up surprisingly rarely. And, if I'm being honest, I'd consider most of the uses of generics I've seen the average enterprise dev use to be mistakes.
- no inheritance
- error codes with explicit handling everywhere
Go just assumes if you satisfy the interface, you’re good.