Axel provided good insights about the history and the big picture of generics. Since the beginning, not having generics was not a goal - or a promise.
>From Computer Science - Brian Kernighan on successful language design <https://youtu.be/Sg4U4r_AgJU?t=3451>: "Perl's time has passed because it has stopped evolving in some sense and Perl 6 is never going to arrive really. So Perl, in some sense missed the boat permanently". Go covers operational system programming and infrastructure programming as well as application programming. The requirements for these two sides might differ drastically. For example on the infrastructure programming side, raw performance might be a requirement itself, so the importance of the code to be descriptive and be aligned with a domain language drops. On the other hand, while Go provides a perfect set of language constructs, to apply all sort of decomposition best practices (the classics like SOLID), having generics, makes it possible to push these boundaries further (like applying DRY - when it makes sense - and being more descriptive in cases that we need to apply generic transformations/policies). On Wednesday, December 23, 2020 at 7:21:41 PM UTC+1 ren...@ix.netcom.com wrote: > I meant success, as in ‘developer acceptance/enthusiasm’, not necessarily > commercial success. > > On Dec 23, 2020, at 9:48 AM, Space A. <reexi...@gmail.com> wrote: > > Prime driver of Java's success were enterprises with huge amount of > investments (money) into ecosystem along with all JSRs developed by > companies and groups with J2EE becoming de-facto a standard for building > enterprise applications. And all this was happening way before any generics. > > среда, 23 декабря 2020 г. в 16:43:46 UTC+3, ren...@ix.netcom.com: > >> To add some weight to the pro generic side - from someone who doesn’t >> necessarily think Go needs them - generics and more specifically the “Java >> Collections” package was a prime driver in Java’s success. Moving highly >> tuned and verified implementations into the core library removed a huge >> burden on developers - allowing them to focus more time on application >> structure/function rather than nuts and bolts - while gaining greater >> “readability” as these apps used common/well known apis as a foundation. >> >> On Dec 23, 2020, at 7:14 AM, 'Axel Wagner' via golang-nuts < >> golan...@googlegroups.com> wrote: >> >> >> >> On Wed, Dec 23, 2020 at 1:17 PM Martin Hanson <greenco...@yandex.com> >> wrote: >> >>> @Ian, for more than 10 years we have managed nicely without generics. >>> >> >> Of course, this doesn't answer how we'd have managed *with* them. >> >> We did manage for decades without general purpose CPUs. We did manage for >> several decades without functions, coroutines or hashtables. We did manage >> for decades without portable programming languages or multi-tasking >> operating systems. We managed for many decades without the internet or the >> world wide web. >> >> In hindsight, though, "we managed so long without them" doesn't appear >> to be a very convincing argument to not have them today. >> >> >>> So what is the real true-life problems that validates adding generics >>> to Go? I haven't seen a single example, seriously not one! I have only >>> seen useless examples like the one Ian gives in the talk, which of >>> course I know only serves as an example, but we need real life problems >>> to solve, not theoretical ones. >>> >> >> To me, this suggests that the issue isn't that you haven't seen enough >> examples, but that you haven't found them convincing you that the benefits >> outweigh the costs. Which is a completely valid position to take. >> Obviously, lots of other people (at least some of which you, I think, >> respect professionally) see that differently. Which is also completely >> valid. So, confronted with that reality, there are many productive ways to >> react. Some examples are >> >> • Try to engage in the design process to keep the cost down (i.e. suggest >> simplifications to the generics design) >> • Try to engage in the design process to increase the benefits (i.e. >> suggest improvements that increase its power) >> • Accept that it's possible for reasonable people to look at the same >> problem and proposed solution and agree on what the costs and what the >> benefits are, but weigh them differently, just as a matter of personal >> taste or opinion - and thus agree to disagree >> • Try to change the other persons mind about what the costs or benefits >> are and how much they weigh >> >> Now, that last one *can* be very productive. Especially early on in a >> discussion, we tend to overlook hidden costs or surprising benefits and >> having them pointed out can be really helpful. Personally, though, I must >> say that the generics discussion has been going on for 10 years (and even >> more, if we don't limit ourselves to Go) and I don't - personally - believe >> that there is much hidden cost or surprising benefit left to be discovered. >> And ISTM that swaying someone's mind on them will most likely take more >> than just outright saying that you don't agree. >> >> So, I guess the question really is, what's the goal? Do you want to get >> the best language? In that case, I'd personally suggest to focus on >> improving the generics design. Or do you want to convince others that their >> valuation of costs and benefits is inaccurate? In that case, I'd personally >> suggest to try and find new costs or benefits - but keep in mind, that 10 >> years is a lot of time for a lot of them to already have been mentioned a >> lot. Or do you just want to be heard as being in disagreement? That's also, >> of course, valid. >> >> What I understand from all of this is that people who are pro-generics are >>> in reality really talking about something that is *nice to have*, not >>> something that is seriously needed and this is where I become really >>> frustrated! >> >> >> I understand this frustration. But it might help to keep in mind that >> computers are simply nice to have in exactly the same way. >> And I think there's an opportunity to have empathy with people who *are* >> in favor of generics. Because just like you are frustrated that generics >> are just nice to have (i.e. you perceive their actual benefit as >> insignificant), people on the other side of the aisle might be *just as* >> frustrated by you, because generics are just slightly more complex (i.e. >> they perceive their actual costs as insignificant). Your frustration is >> valid, but so is theirs. >> >> As I have said many times now, adding stuff to Go comes with >>> a heavy price, it opens the door for all the people who have been whining >>> and complaining about Go for the past ten+ years to add further stuff >>> that >>> is "nice to have", or change things they keep complaining about, like how >>> Go handles errors and what not. >>> >>> After generics gets added, it's going to be something else next time, and >>> again and again. The list goes on and on about changes people want to >>> make to Go. Not real life problems, just so-called "nice to have". >>> >>> No, the added and increased complexity I have witness in other >>> programming languages over the past 3-4 decades, because of exactly >>> things like this, is absolutely mind blowing. This must not happen to Go! >>> >>> -- >>> 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...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/17246551608725779%40iva4-6593cae50902.qloud-c.yandex.net >>> . >>> >> >> -- >> 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...@googlegroups.com. >> >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFVeWZcnMtWQ3gZNeJ46GUFr68yYZtVa1YNmpQtbV-8yA%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFVeWZcnMtWQ3gZNeJ46GUFr68yYZtVa1YNmpQtbV-8yA%40mail.gmail.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...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/5bc14220-c09f-4920-a11c-7bc2d9d3896cn%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/5bc14220-c09f-4920-a11c-7bc2d9d3896cn%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/5c3114cd-fcf4-4c17-aa92-026a8bb092b8n%40googlegroups.com.
