On Monday, September 17, 2018 at 9:04:26 AM UTC-7, jucie....@zanthus.com.br wrote: > > Go core team is working hard to bring generics to the language because > several people asked for it. With all due respect for those users and for > people working hard to make generics a reality, I feel that a greater > number of people would suffer after generics adoption. So, I feel compeled > to manifest my opinion: sorry guys, Go with generics will be worse than Go > without generics. >
I think you're right, that adding parameterized typed method invocations will add complexity, and therefore people will suffer more. However, to me, it isn't obvious, without a final proposal against which to assess that concern, that the pain will outweigh the gain. Certainly, the existing proposal suffers from at least one area of considerable additional complexity - "contracts" - which is both a great way to address the problem space, and an area of new complexity incompatible with Go's existing language choices. I look forward to seeing the next round of drafts and how they incorporate concerns about contracts. > > The language strives for simplicity since its inception and that is what > attracted a large part of its user base. We must think about who we will > want to have in our community 10 years from now. Supporting generics would > please a minority to the detriment of a large number of potential users. > What pushes me in the direction of encouraging attempts to address the missing language feature of generics are two aspects: - Copy and paste coding is an enormous source of errors, and to the extent that generics addresses some of those scenarios, that is a big win for the language and the developers. Writing yet another "for ... range" loop to perform the same mutation on a very similar type is not a big deal the 2nd time, but by the time I've had to do that for a fifth time, I'm unhappy about it, for sure. (YAFRL - "yet another for ... range loop") - Go already has "generic" capabilities. "range", channels, select, and type-casting are generic language constructs, "Make", "copy", "append" all provide generic functions, and maps and slices are generic data structures. Developers certainly do not have a problem using the existing "generic" capabilities of the language, so I think there's a case to be made that they will not consider additional "generic" capability that much harder to absorb. > Today Go is easy to learn and tools are easy to implement. Please keep it > that way. > I agree with that sentiment! Eric. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
