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.
