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 wantedthey 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). This issue seems to have resonated with a lot of people, which may be an important data point when considering the try proposal, 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.
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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to