I agree that it makes the suitable trade-offs. And Linq is doing pretty well without generics (https://github.com/ahmetb/go-linq); not familiar with Rx.
When I consider the dilemma, the two things I don't want are slow programmers and slow execution, leaving "slow compilers and bloated binaries". But here is how I think about this option: - There are alternatives that only impact compiler speed if they are actually used. I think that's fair. - There are alternatives that result in binaries hardly any larger than if you copy-pasted. Again, I think that's reasonable. As I understand it, the package template approaches fall into this camp. So with the above restrictions, count me in favor of slow and bloated :-) On Sunday, March 26, 2017 at 9:08:20 AM UTC-4, Egon wrote: > > On Sunday, 26 March 2017 15:30:30 UTC+3, Mandolyte wrote: >> >> @Bakul - is your approach documented in Egon's collection? I think it is >> essentially the same as Egon's at >> https://groups.google.com/d/msg/golang-nuts/JThDpFJftCY/1MqzfeBjvT4J >> >> Perhaps your syntax is cleaner, simpler. I also like this general >> approach. In Egon's document, this approach has nearly no downsides. >> > > Depending what do you want to use generics for, there are significant > downsides. Mainly, you cannot create chained general purpose functions... > e.g. LINQ, Rx... *in the summary document see problems "functional code" > and "language extensions".* > > You could argue that using such approaches is not good for Go... but this > wouldn't invalidate that this generics approach doesn't solve these > problems nicely. > > You are always making trade-offs. > > *Personally, I think it makes trade-offs that are suitable to Go... but I > understand why people would disagree with it.* > -- 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.
