On Wed, Jun 22, 2016 at 2:55 PM, Viktor Kojouharov <vkojouha...@gmail.com> wrote: > > And yet the 'K' and 'V' within the struct are generic types. A struct is > never simple. That's its whole point. >
I don't know what you mean by that. A struct is very simple, it's flat data. > A lot of these 'applications' that you think are the language's main > target are built on top of libraries, including stdlib, written by that > same language. And these same libraries can benefit from having generics, > once again, including stdlib. > I agree. But I also think they can suffer from them. And I don't find it at all obvious which effect will dominate. From my experience with other languages, the overall effect will probably be negative, because the number of places where they help is very small, whereas the number of places where they hurt and are still being used (judging, again, from other languages) is very large. > I've found this type of thinking quite poisonous. The "lets bereave > ourselves of something universally lauded as useful, because it _might_ be > used in the wrong manner by some people" mentality is just wrong and > prevents any kind of useful evolution under any context. > Again, I am judging here from my experiences with other languages that do have generics and I am also taking into account the arguments brought forth by people proposing them for go. There is strong evidence that the correct phrasing is "will", not "might". And yet this hasn't stopped people from successfully learning and utilizing > languages that have generics are part of their specifications. > Yes, but I haven't claimed impossibility, but hardship. Let's look at it from this way: If generics are as indispensable as claimed here, why are people still using go then? For years the adoption of go has grown, not dropped, especially for large-scale applications and despite a lack of generics which is painted as a necessity. That just doesn't make any sense. I'm claiming that the reason go is still being used is *because* it's lack of generics (and other features), rather than despite of it. It's because it's a comparatively simple and easily understandable language. > The fact still remains that unlike a lot of other proposed languages > additions that are immediately dropped, generics are still open for > discussion by the language developers themselves. > Yes. And I would treat proposals by the go team very differently from the random repeated proposals to golang-nuts by people I have never heard of. Because they've come up with the language as I like it and I trust them to not add a proposal that goes contrary to it's spirit. > I'm sorry, but that's just fearmongering. Unless you have some kind of > magic crystal ball, there's now way you'd know how the quality of go code > will change. You don't even know what the implementation will look like ... > As mentioned above, I'm working from my experience with languages that currently have them and from examples people have put forward to justify their need. As most if not all "wild" proposals so far have argued from a standpoint of existing implementations and tried to apply existing implementations to go, I consider that very fair. -- 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.
