Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

[Jon Conradt]

I have been following the various proposals for changing error handling in 
Go since the beginning. Recently I've decided I probably would not use them 
and I would stick with the explicit error checking. While verbose and 
repetitive, in my opinion it is the easiest to read and understand.

I've begun to wonder why the language should be changed when we could just 
make it easy for editors to anticipate the need for the boilerplate and 
provide it. Others have mentioned macros, and for me that solves the 
repetition and keyboarding issues.

My vote is to not change the language, but to change the editors (or even 
gofmt).

Jon

-- 
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/487c8495-241a-48c9-b7b0-a14dc9d0c38c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

[Russtopia]

Score one in support for this, from the "peanut gallery" of "experienced
programmers in other languages, but only around 2 years of Go". I thought
at first that if err != nil { ... } seemed clumsy, but I myself don't like
exceptions and implicit flow control constructs much and the more I used
Go, the more natural it felt. If anything, a way to pretty-print stack
traces would be the main thing I'd like to more quickly parse failure
paths, though I have seen at least one project already that does this so it
needn't be a core part of the language.

A gofmt one-line with return style as described here seems like a very nice
balance to me.


On Tue, 2 Jul 2019 at 19:41, Dave Cohen  wrote:

>
>
> On Friday, June 28, 2019 at 5:44:01 PM UTC-7, 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.
>>
>
> I've noticed that `go fmt` generally format funcs into multiple lines, but
> does allow one-liners. That is, it will leave a function like this as just
> one line:
>
> func statusUpdate() string { return "" }
>
> (For more examples, grep "{ return" in the standard library.)
>
> While I know that "one line if statements" have been discussed and
> over-discussed, I'll go out on a limb and suggest maybe `go fmt` should
> allow a "one line if" in one circumstance...are you ready for it? when
> the then clause contains only a `return ...`.
>
> This means the following would be allowed by `go fmt`...
>
> if err != nil { return err }
>
> or
>
> if err != nil { return fmt.Errorf("I like to wrap my errors: %s", err)
> }
>
> This makes error handling more concise, by some lines, in those cases
> handled by the `try` proposal.  And also more concise while allowing
> wrapping or testing for error values other than nil.
>
> It's a modest proposal in that it only saves lines of code.  It requires
> no language changes, just `go fmt` changes. This would be analogous to what
> `go fmt` already allows in one line funcs, and in my opinion would not
> negatively affect readability.  If enough folks here reach out to me
> supporting this idea, I'd submit a proper proposal.
>
> --
> 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/42b8fc5d-2f0a-4951-8ca5-0476e23fd4a7%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/CAN4yCu-pgQfFkoHPvrSF9DmrK%2BXs9ju6t7%2BS81z-F0U_TMqBGQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

[Robert Engels]

I never disputed that there were (in both camps). I disputed the original argument that preferring the input of people with extensive Go experience, over minimal Go experience was a valid approach, and argued that approach was short-sighted and error prone (for the reasons cited).Not to fan any unrelated flames, but I would rank experience > wits > education. Ideally you have an abundance of all three, but only the first and last have a time component (and by experience I am referring to expert experience, as in an 'expert plumber'), but its also very hard to get the first, without the other two.-Original Message-
From: Henrik Johansson 
Sent: Jul 1, 2019 1:22 PM
To: robert engels 
Cc: David Suarez , golang-nuts 
Subject: Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

I am not making this argument but you are continuously referring to experienced developer's preferences (perhaps someone else more if so I am sorry).Don't get me wrong. Experience is good and weigh a lot especially combined with education and wits. Perhaps we can both concede that there are such developers in both camps.On Mon, Jul 1, 2019, 19:21 Robert Engels <reng...@ix.netcom.com> wrote:I don't think that has anything to do with what I said.I stated that experienced developers with minimal Go experience can probably offer deeper insights than new developers with only Go experience.The Go team is experienced developers (at least the ones I know), AND have deep Go experience (I am assuming - but maybe not on the Go application vs internal development side).If you are making the claim that the Go team "knows all", then why even have these conversations in the first place? Why have any community involvement at all? I am pretty sure this is not the position of the "Go team".-Original Message-
From: Henrik Johansson 
Sent: Jul 1, 2019 12:14 PM
To: robert engels 
Cc: David Suarez , golang-nuts 
Subject: Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

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 languageFrom 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 runI 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 th

Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

[Henrik Johansson]

I am not making this argument but you are continuously referring to
experienced developer's preferences (perhaps someone else more if so I am
sorry).

Don't get me wrong. Experience is good and weigh a lot especially combined
with education and wits. Perhaps we can both concede that there are such
developers in both camps.

On Mon, Jul 1, 2019, 19:21 Robert Engels  wrote:

>
> I don't think that has anything to do with what I said.
>
> I stated that experienced developers with minimal Go experience can
> probably offer deeper insights than new developers with only Go experience.
>
> The Go team is experienced developers (at least the ones I know), AND have
> deep Go experience (I am assuming - but maybe not on the Go application vs
> internal development side).
>
> If you are making the claim that the Go team "knows all", then why even
> have these conversations in the first place? Why have any community
> involvement at all? I am pretty sure this is not the position of the "Go
> team".
>
> -Original Message-
> From: Henrik Johansson
> Sent: Jul 1, 2019 12:14 PM
> To: robert engels
> Cc: David Suarez , golang-nuts
> Subject: Re: [go-nuts] Re: The "leave "if err != nil" alone?"
> anti-proposal
>
> 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  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

Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

[Robert Engels]

I don't think that has anything to do with what I said.I stated that experienced developers with minimal Go experience can probably offer deeper insights than new developers with only Go experience.The Go team is experienced developers (at least the ones I know), AND have deep Go experience (I am assuming - but maybe not on the Go application vs internal development side).If you are making the claim that the Go team "knows all", then why even have these conversations in the first place? Why have any community involvement at all? I am pretty sure this is not the position of the "Go team".-Original Message-
From: Henrik Johansson 
Sent: Jul 1, 2019 12:14 PM
To: robert engels 
Cc: David Suarez , golang-nuts 
Subject: Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

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 languageFrom 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 runI 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 hereOn 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.

Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

[Henrik Johansson]

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  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

Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

[Robert Engels]

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 languageFrom 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 runI 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 hereOn 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.

Re: [go-nuts] Re: The "leave "if err != nil" alone?" anti-proposal

[robert engels]

I think the hostility stems from the fact that there are two very distinct 
camps (sort of mirrors the current political world). There are those that think 
the current Go way is fine, and no need to fix it. There are others that think 
it needs to be radically overhauled (and that ‘try’ doesn’t go far enough) - so 
neither camp is happy, and maybe both feel that the change is an appeasement 
and maybe ‘change for change sake’/marketability, and that’s bound to make both 
sides (with strong beliefs as you state) kind of frustrated and maybe angry.

People don’t like change, and they don’t like compromise while it is happening, 
but they often realize it was the best course of action at a later date.

Although I agree with you that the subject is easy to grasp, I don’t think that 
necessarily makes the solution easy. What is “best” heavily depends on the 
use-case, and with a general purpose language, you end up with conflicting 
“bests”. Which is why I’ve argued for quite a while that for Go to truly 
succeed, it needs to define what it is primarily used for, and then the 
language constructs and facilities can align. A lot of the complaints around 
Java is that it has become so large (and complex) - and the reason being it 
tries to be all things to all people. Often the hardest thing to do when 
designing software is to know what to leave out, and I think the Go elders have 
done a admirable job here. It is the community, mainly the developers that have 
invested time/effort in learning & championing Go, that want to expand its area 
of influence (and complexity) - not coincidentally increasing their value at 
the same time.


> On Jun 29, 2019, at 3:28 PM, diogoid7...@gmail.com wrote:
> 
> On Saturday, June 29, 2019 at 1:44:01 AM UTC+1, Tyler Compton wrote:
> ... 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.
> 
> I agree with you. Maybe that's not what the author intended, but to me that 
> anti-proposal feels like a giant middle finger to everyone - myself included 
> - who feels unhappy with the current state of Go error handling. I think the 
> quality of that discussion really just reflects its non-constructive nature.
> 
> At risk of stating the obvious, I think we're being badly bitten by the 
> bikeshed effect here; the subject under discussion is relatively easy to 
> grasp, and so we get a litany of both counter-proposals (which has even 
> happened before - see proposal: Go 2: simplify error handling with || err 
> suffix ) and zealously-held 
> opinions.
> 
> I also must say that I feel dismayed by how negative the tone of the 
> conversation around the `try` proposal has been. I would certainly not expect 
> everyone to like it as much as I do, but some people seem frightened or 
> affronted by it far beyond what I'd consider reasonable.
> 
> -- 
> 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/7573beb9-9c85-461d-9c3d-96b73b891c8b%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/A1D496D5-C302-405F-A050-897EBF4D4305%40ix.netcom.com.
For more options, visit https://groups.google.com/d/optout.