This is funny since you are perfectly describing the Go core team... ;) I really can't get my head around it that this topic generates so much vitriol (maybe harsh). Generics I kinda get but this is just incredible. Don't like try? Don't use it.
On Mon, Jul 1, 2019, 18:42 Robert Engels <reng...@ix.netcom.com> wrote: > I think that is going to suffer greatly from sampling bias. > > You may have an engineer with 20+ years of programming in a variety of > languages - using both exceptions, and error values, and be new to Go, but > still have substantial insight as to the relative merits and drawbacks of > proposed options. > > In fact, I would argue that it is these experienced engineers that can > foretell the "end result" of various paths with far greater accuracy than a > new developer with multiple years of nothing but Go experience. > > Nothing is new, it is an impedance matching exercise. > > > -----Original Message----- > From: David Suarez > Sent: Jul 1, 2019 11:16 AM > To: golang-nuts > Subject: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal > > The number of posts on this topic piqued my curiosity so I hope to add > some considerations after doing some research on this trail that I hope you > find useful. > > TL;DR: It is possible that the reason for the interest in improving > "exception handling" in the proposed way is driven by individuals that are > not yet fully comfortable in the language > > From what I have gathered, the reason for improving this area was due to a > Go Survey. This reminds me of this popular quote: > Quote. “*If* I had *asked* people what *they wanted*, *they* would have > said faster horses.” Henry Ford, Innovation, > > Please note that while I did not participate in the survey, I would > probably have said the same thing until I got "used to it". The > interesting support bit from the survey was the answer to, "I have used Go > for..." - suggests that 1/3rd of the respondents have only 1 year > experience or less with the language and a full half have less than 2 years > experience. In my experience, when I started Go I was (and still am in some > cases) using some Java paradigms in them that make sense to me which is > great for transition but may not be great for the language long run > > I am sure folks that have been around a while would agree that some of the > reasons they are considering or actively changing languages tend to be due > to bloat and unnecessary features that eventually weigh down productivity > because there are 10 ways to skin the cat and everyone has a different > opinion due to either how the rest of the code base does it or what is > new. > > The large response to this thread suggests that potentially there may be a > better feature out there that merits some attention and I would suggest it > may be something that should come from the 2+ years experience crowd (if > weighting of the results is possible) as those are likely the challenges > that newbies like me will eventually encounter. Weighing the survey > results by experience may help Go stay ahead of the curve. Just my .02 > > ** Side note: I am a relative newcomer to Go (~8-9 months) so there is > likely some bias there from my newness. Add salt here.... > > On Friday, June 28, 2019 at 7:44:01 PM UTC-5, Tyler Compton wrote: >> >> If anyone hasn't seen it, an issue with the "proposal" tag was created >> earlier on the Go issue tracker titled "Proposal: leave "if err != nil" >> alone?" (here <https://golang.org/issues/32825>). This issue seems to >> have resonated with a lot of people, which may be an important data point >> when considering the try proposal <https://golang.org/issues/32437>, but >> I was surprised to see how poorly the discussion has gone. There are quite >> a few "me too" comments, a few image-only posts, some less than stellar >> personal conduct, and overall not a lot of nuanced discussion. I feel that >> perhaps these kinds of anti-proposals should be discouraged because they're >> inherently reactionary, which seems to get the discussion off on the wrong >> foot. >> >> That said, this anti-proposal attracted a whole new group of Go users >> that I don't remember from the original try proposal discussion, which was >> mostly dominated by ten or twenty participants. The discussion was better, >> but the number of active users was much smaller. I wonder if there's a way >> to better engage a larger portion of the Go user base while still >> encouraging healthy, technical discussion. >> > -- > 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/1284af52-5fd6-4cd0-9bd3-cc69fd1c2fc7%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/1284af52-5fd6-4cd0-9bd3-cc69fd1c2fc7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > > > > -- > 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/974016176.5469.1561999325924%40wamui-cheeto.atl.sa.earthlink.net > <https://groups.google.com/d/msgid/golang-nuts/974016176.5469.1561999325924%40wamui-cheeto.atl.sa.earthlink.net?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAKOF696VzX3LeZr2AJ2-tzuGfoPcq6tsXR8yiotHo%3DRF5pT2Kw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.