Another dimension is "intellectual complexity." Where that is smaller, everything else is better for coding, documenting, debugging, testing, reading, using, and maintaining.
It is a critical measure for maintaining the 'Go' of Go. On Sun, Mar 26, 2017 at 11:40 PM Egon <egonel...@gmail.com> wrote: > On Monday, 27 March 2017 04:06:17 UTC+3, Mandolyte wrote: > > 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. > > > The unfortunate reality is that when you add generics to a language it > will be almost impossible to avoid it. > > And the dilemma is not a binary-yes-no... e.g. would you give 100x > performance to have fast programmers, fast execution and no code-bloat... > or would you give 10% performance for medium speed programmers, fast > execution and some code-bloat? > > It's better to view the dilemma as a rating system. As a facilitated > example: > > *copy-paste:* > 1. convenience: 0/10 > 2. code size: 10/10 > 3. performance: 10/10 > 4. flexibility: 10/10 > 5. readability: 5/10 > > *interfaces:* > 1. convenience: 4/10 > 2. code size: 0/10 > 3. performance: 2/10 > 4. flexibility: 6/10 > 5. readability: 8/10 > > *type-level generics with boxing:* > 1. convenience: 7/10 > 2. code size: 0/10 > 3. performance: 5/10 > 4. flexibility: 8/10 > 5. readability: 1/10 > > *package-level generics with out-of-bounds boxing:* > 1. convenience: 6/10 > 2. code size: 3/10 > 3. performance: 8/10 > 4. flexibility: 5/10 > 5. readability: 7/10 > > *Obviously, do not take these numbers seriously.* > > - There are alternatives that result in binaries hardly any larger than if > you copy-pasted. Again, I think that's reasonable. > > > Here you are making a trade-off... it's not just about size, but also > about performance. More code means more icache misses. > > The main point is that *"there are approaches that produce less code than > copy-pasting"*. So ideally we want smaller binaries than you would get > from copy-pasting. > > 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 :-) > > > Not necessarily. I suspect it will be faster to compile than most generics > packages and similarly dealing with bloat will be easier. > > > 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.* > > -- Michael T. Jones michael.jo...@gmail.com -- 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.
