Pillsy Wrote: > jfd wrote: > > > == Quote from Andrei Alexandrescu (seewebsiteforem...@erdani.org)'s article > > > >> eaturbrainz > > >> Back in the day I was writing a kernel, and having to > > >> rewrite queues for every single type of thing I wanted > > >> to queue, or use type-casts to enforce strong typing > > >> of queue elements at runtime, was annoying as fuck. > > > http://www.reddit.com/r/programming/comments/e49ta/go_one_year_ago_today/ > > > eaturbrainz's problem is what convinced me of the true value of > > generics. > > At this point I'm mystified as to why language designers just keep on making > this same mistake by leaving support for generic programming out of their > statically typed languages. Java and C# had to graft generics onto their > languages after the fact; why ignore that?
Can you please explain when have you missed them? Because after writing quite a bit of Go code, and talking with other people that has written even more Go code, almost nobody has found this to be an issue. Specially now the new append() builtin has taken care of most of the remaining cases where generics might have been marginally useful. Saying "what if" is easy, I'm still curious about in what real circumstances this "ifs" are satisfied, if you have run into any such cases while writing Go code, I would love to hear about it. Again, I'm not saying this doesn't happen, but that it is not as problematic in practice as many people that have never used go seem to claim. The question is: can you provide real world examples when that is a problem? I can think of a few, but it is quite rare, and in those cases it is quite painless to build your own data structures specific to whatever data you are handling. Because nobody ever reused any code in languages without generics!
