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