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.* >> > -- 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.
