This conversation makes me want to consider whether there's a way to solve the problem that Generics solves, but solve it in a different way. This discussion bears a lot of similarity to the argument about inheritance, and Go solved that issue rather elegantly with interfaces - describe the behavior you need instead of the types you'll accept. I'm wondering if there's a way to do the same thing with this problem. As I understand the proposal right now (and honestly, I don't understand it fully, and that's part of the issue) a function signature can either say "I will only accept a value with type X" or "I will accept a value with any type." Could there be another option? In Ian's reversing example, could the function signature say "I will accept an integer or a string, (but not a struct or a map)"? Or even better - Is there a way for the function signature to say, "I will accept any type that can be compared as greater-than or less-than"? This feels very Go-y. That way, by looking at the signature, you know what the function is going to try to be doing with it. But you also get the benefit of not having to write and maintain two essentially identical pieces of code that differ only by their type.
This is less than half an idea, because I don't know exactly how you would do that. I'm hoping this thought will spur creativity in someone else. Maybe there could be some built in "generics" (using this term in a different way) like "Comparable" or "Addable" or "Sortable" or something, and you could use those keywords as a type in your function signature, but under the covers, the compiler would determine whether the value's type conforms. That's not a great idea, but maybe someone can improve on it? Or could there be something similar to interfaces, where a property (or set of properties) could be required instead of a set of methods? Could built-in primitive types have properties added as Comparable or Addable or something? Again, this solution feels clunky and not the right answer, but it feels like there's a great solution somewhere in this direction. On Wed, Dec 30, 2020, 8:37 AM Vivi <createmap4...@gmail.com> wrote: > I'm sure my thought is off-topic and is not applicable, I shall give a try > after seeing the trends in programming and non-programming world. There is > an "overlap" between Generic and non-Generic. If it can be solve between > the two sides, that's easy with "translation" to and back? > > When we have a language barrier, Google Translator makes that possible or > ignore everything I said here. > When Go can cross-compile to different OS architectures, it could be > applicable for source code as well. > > On Wednesday, 30 December 2020 at 20:27:15 UTC+8 Space A. wrote: > >> Go doesn't have classes and is not an OOP language. >> >> Classes (like in Java) vs structs (like in Go) is about inheritance vs >> composition, not about attaching fields and methods. Inheritance implies >> type hierarchy, child and parent, virtual functions, abstract and final >> implementations and so on so forth to keep this all of this manageable. >> >> >> >> вторник, 29 декабря 2020 г. в 23:27:45 UTC+3, Alex Besogonov: >> >>> Please, stop being so condescending to newcomers and non-professional >>> developers. Generics as uses by end-users will improve their experience, >>> not make it harder. >>> >>> (And what is this obsession with "classes"? Go has them - structs with >>> methods are classes). >>> >>> On Tuesday, December 29, 2020 at 1:32:30 AM UTC-8 >>> rickti...@googlemail.com wrote: >>> >>>> My point of view is that Generics should not become part of the Go >>>> standard library. I appreciate there are use cases where it is very helpful >>>> to have, but I do not believe that adds value to Go. The real value for Go >>>> is it's simplicity, avoidance of generics and avoidance of classes. This >>>> makes the language accessible and approachable to all, which is >>>> increasingly more valuable. Go appeals to new-comers and experienced >>>> developers because it is simple, and comfortable. The rate of uptake in >>>> computing technology is still subject to Moores law, and today we see a new >>>> type of programmer emerging, the 'citizen developer'. >>>> >>>> Go follows time proven computational concepts, it does not follow the >>>> 'new paradigm' tribes, it's roots are firmly planted in statically typed >>>> procedural/functional programming techniques, and this maps well to much of >>>> the literature available. The growth of entry level developers ( aka >>>> 'citizen developers' ) will be exponential over the next decade, and in >>>> that landscape it is Go's simplicity that will win the day. >>>> >>>> On Monday, 28 December 2020 at 17:35:40 UTC L Godioleskky wrote: >>>> >>>>> " If generics gets added to Go, we're opening a very dangerous door, >>>>> and >>>>> it will be the downfall of Go because - and Robert Griesemer this is >>>>> especially addressed to you - what's next then? Seriously, what's >>>>> next? ... " >>>>> >>>>> .. AI, followed by cryto currency and asexual repoduction >>>>> On Tuesday, December 22, 2020 at 5:09:05 AM UTC-5 Martin Hanson wrote: >>>>> >>>>>> No polls. It's not a matter of majority rule! >>>>>> >>>>>> It's a matter of understanding why generics was left out of Go from >>>>>> the >>>>>> start, like classes was left out of Go. If we start adding stuff that >>>>>> the original developers of Go left out by purpose, we're not >>>>>> understanding the design choices that went into Go, which is exactly >>>>>> what makes Go unique! >>>>>> >>>>>> Go was a major slap in the face to all the hype that has polluted the >>>>>> programming industry for the past 30-40 years, which is why Go got so >>>>>> much hate in the beginning from all the hype loving people. >>>>>> >>>>>> If you want to add generics to Go, if you want to change how errors >>>>>> are >>>>>> handled, if you want X, Y or Z feature that Java, C++, or some other >>>>>> complex language has got, then go use that language! Why are you even >>>>>> here!? >>>>>> >>>>>> The design choices that went into Go was not made randomly, nor were >>>>>> they made by just anyone. Please understand that the people who >>>>>> designed Go, and we all know who they are, had/has tons of experience >>>>>> and the pragmatic approach they took is what make Go stand out so >>>>>> beautifully! >>>>>> >>>>>> If generics gets added to Go, we're opening a very dangerous door, >>>>>> and >>>>>> it will be the downfall of Go because - and Robert Griesemer this is >>>>>> especially addressed to you - what's next then? Seriously, what's >>>>>> next? >>>>>> Let the community decide by majority!? Is that how we design a >>>>>> professional programming language now? By majority rule?! NO! The >>>>>> majority is all about hype and shine. >>>>>> >>>>>> Adding generics to Go will rip out the spine of the philosophy of Go >>>>>> and I for one will not be a part of that. I have more than 30 years >>>>>> of >>>>>> experience in the business and I fully understand why generics and >>>>>> classes and all the other clutter was left out of Go. >>>>>> >>>>>> If generics gets added to Go, we're a big enough part of the >>>>>> community, >>>>>> that passionately hate that, that we can manage to fork Go - which I >>>>>> strongly believe will then be the right thing to do! >>>>>> >>>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/LEEuJPOg0oo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/cef57f9c-f641-4887-8cca-675613e8be37n%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/cef57f9c-f641-4887-8cca-675613e8be37n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CA%2Bj6mhDjqjXVMJ8q52cYDKfxrf9dUA90kuB%2BTg2G57KtCEiPWg%40mail.gmail.com.
