Folks, is this something that we should do with a template processor? More topically, is this a set of somethings that we should prototype each of, using templates?
I'd love to see actual experiments in computer "science" (;-)) and a debate about the tradeoffs based on code. --dave On Monday, March 27, 2017 at 2:40:12 AM UTC-4, Egon 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.* >>> >> -- 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.
