I want to emphases that go generate is so far an awesome solution, but not a definitive answer.
Yes, it could made easier, about that, its already great that all the tools we need are written in go itself, this is really really really helpful. On Monday, June 5, 2017 at 5:59:46 AM UTC+2, utyug...@mail.com wrote: > > > > On Sunday, June 4, 2017 at 12:25:17 PM UTC-4, Egon wrote: >> >> I think you are missing the point of my comment. >> >> I'm all for generics, but I also can survive without them without much of >> a problem. (I'm even maintaining >> https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4 >> >> to understand the problem better) >> > > create a custom container type that I can use with any type out-of-the-box. > > for example: iset := make(Set[int],9); sset := make(Set[string],9); pset > := make(Set[Person]); > > right now, my solution is to rewrite the source with go generate calling a > tool i wrote which grew out from a great talk from robert griesemer. The > video: https://www.youtube.com/watch?v=vLxX3yZmw5Q > > This solution has nearly twice the performance increase over maps with > almost every type used so far. Now I could have just written the 500 lines > of code over and over again for every type needed until the end of time(or > copy and paste and edit until the end of time), or I could use empty > interfaces which throws type safety out the window, but I chose to write a > tool, and when go generate came to be I chose to use that tool like a > simple script executed within a '//go:generate go run..' tag. > > > Over time golang(I do this now to annoy the zealots) provided the > tools(reflection, /go packages, go generate) that made creating custom > generic type safe containers easier. These things weren't always this easy, > and these things could be easier. > > And I am serious about create a custom container type that I can use with > any type out-of-the-box. Please indulge me, how would you solve this > problem. Provide a solution for a simple type-safe container type Set that > takes any type, with a simple api of > insert,remove,contain,union,difference,intersection, > complement,superset,subset. > > I've seen you provide solutions in the past, so I would like to see your > solution to this not-much-of-a-problem. > > >> >> The issue I was trying to highlight was that you are proposing solutions >> to a problem, but other people don't know what your exact problem is. Hence >> my 3 lines version are equivalent in their result and value, because the >> problem is missing. >> >> Similarly, when we don't have a concrete problem we could over-engineer >> the generics or alternatively solve the wrong problems. >> >> For example, when the solution you propose only solves 5% of the problems >> that generics needs to solve... or vice-versa... a generics solution 100x >> simpler would solve 99% of the cases... then what is the value of the >> proposed solution? >> >> So, which of the 147 different generics approaches/implementations works >> better for Go and why? (I'm also counting the ones that aren't known yet :D) >> >> When you would use a real-world example and problem, it would be possible >> to argue that one approach is better than the other... without one, this >> discussion doesn't lead to anywhere. >> >> + Egon >> >> On Sunday, 4 June 2017 19:09:17 UTC+3, mhh...@gmail.com wrote: >>> >>> given the fact that actually everybody disagrees on that idea, >>> or even something similar according to some feedback. >>> >>> I want to put the question differently. >>> >>> My mean is to say that golang is a basis to build upon in general that >>> is better >>> than other existing solutions. >>> >>> imho, golang is governed by its compatibility requirement, >>> and, an extremely vertical approach, >>> which blocks every possible update to the dogma: >>> is it go 1.0 compatible ? >>> >>> And because its vertical, is it to my taste ? >>> >>> The go 1.0 compatibility requirement makes everybody very happy. >>> >>> Still, I dont believe the language is considered as finalized by a >>> majority of users. >>> Some will say it misses generics, some other (..) will try different >>> approach. >>> >>> Why should it be that much of frictions ? >>> >>> Why can t we evaluate a solution where multiple vision co exists ? >>> Handle the change. >>> >>> Aint there existing case of such kind of symbiosis which benefits each >>> other on the long term ? >>> >>> A solution where the go 1.0 requirement is kept valuable, >>> and a new language target where this requirement has been removed. >>> A transpiler to go 1.0 compatible code ? >>> So both can exist ? >>> >>> my 2 cents, >>> that close and negative answer i got, >>> is not helpful nor inclusive, >>> its like take or leave attitude, >>> >>> it d just be more inclusive to say that >>> it is ok to make a transpiler/or whatever it should be/ implementing >>> your idea, >>> check that resource for further implementation come back here for >>> questions. >>> >>> Other consideration, >>> the idea that golang 1.0 is used to build a different language target >>> that compiles back to go1.0, >>> looks cool. >>> >>> On Saturday, June 3, 2017 at 6:24:31 PM UTC+2, mhh...@gmail.com wrote: >>>> >>>> for the fun, with early return, >>>> >>>> https://play.golang.org/p/I9AORKOYQm >>>> >>>> On Saturday, June 3, 2017 at 12:34:15 PM UTC+2, mhh...@gmail.com wrote: >>>>> >>>>> > Generics enable more than just replacing loops. For example, they >>>>> can enable libraries of generic algorithms to be used with any type of >>>>> array. Here's an example: >>>>> >>>>> in my demonstration every type got this kind of method, >>>>> the problem become how do you jump from Type A to type B. >>>>> in []A to []B or A -> B >>>>> >>>>> indeed it works on the item level, no more on the collections. >>>>> >>>>> This question is solved in two ways, >>>>> - interface definitions (not interface value) >>>>> - static conversion, which always resumes to >>>>> func(in-type) out-type >>>>> >>>>> and some alternatives for convenience (producer/consumer) >>>>> func (func(in-type) out-type >>>>> func (in-type) func() out-type >>>>> func (func(in-type) func() out-type >>>>> // this is unfinished explanation it should include error management >>>>> to be handled more completely. see please previous conv() fn introduced >>>>> earlier to statically re decorate a func signature. >>>>> >>>>> So far the sum/reduce things operation, >>>>> i left them as exercise to the stream declarer >>>>> and did not consider them as core. >>>>> Take become => filter (func(10 elements)) >>>>> Map is map >>>>> Sort is All(fn sorter) []out >>>>> Reduce is a map operation, preceded by a conv if it reduces to a >>>>> different type. >>>>> >>>>> >>>>> On Friday, June 2, 2017 at 2:59:41 PM UTC+2, >>>>> gary.wi...@victoriaplumb.com wrote: >>>>>> >>>>>> Generics enable more than just replacing loops. For example, they can >>>>>> enable libraries of generic algorithms to be used with any type of >>>>>> array. >>>>>> Here's an example: >>>>>> >>>>>> foo := GetArray() >>>>>> result := foo.Take(10).map(...).Sort(...).Reduce(...) >>>>>> >>>>>> That is simple to understand and in one line of code. Imagine the >>>>>> acrobatics (and lines of code) needed to do this using Go's loops! >>>>>> >>>>>> You can read my full article on why Go needs generics here: >>>>>> http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/ >>>>>> >>>>>> On Friday, 2 June 2017 09:17:54 UTC+1, Florin Pățan wrote: >>>>>>> >>>>>>> Since everyone thinks it but nobody bothers to reply to it: this >>>>>>> whole thing you propose can be currently done with a for loop, which >>>>>>> not >>>>>>> only is explicit about what it doing, but it also lets you control if >>>>>>> you >>>>>>> want to exit early from it and so on. Complicating the whole language >>>>>>> because something is cool (yet looks like a really complex thing that >>>>>>> you >>>>>>> need to think about while reading the code) is in no one's benefit. >>>>>>> Stop >>>>>>> trying to avoid a couple of extra rows of for {} (where the third row >>>>>>> is >>>>>>> literally just an "}") and start embracing the fact that you can >>>>>>> understand the code by looking at it and not apply any complex mental >>>>>>> acrobatics to figure out what those three lines of code are doing. Your >>>>>>> future self/person after you will thank you for that. >>>>>> >>>>>> -- 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.
