Sorry to f'up on myself, but I would like to add regarding #1: at least my personal impression is that for #1 it looks very difficult to improve this in any meaningful way. It looks to me as if #2 is actually where the improvements would bear large fruit as it makes Go more welcoming and productive to those types of devs and/or types of Go modules, that is, applications.
On Wednesday, August 2, 2023 at 9:27:23 PM UTC+2 TheDiveO wrote: > > Ben Hoyt's blog post Scripting with Go: a 400-line Git client that... > <https://benhoyt.com/writings/gogit/> mentions error handling from a > perspective that made me clear for the first time why I'm always in two > minds when it comes to Go's error handling: > > 1. the perspective of a prod-code package writer that will be used in > larger contexts: "[Go's error handling is] *simple and explicit [...] > It's not a big deal when writing production code, because then you want > more control over error handling anyway -- nicely-wrapped errors, or > human-readable messages [...]*" > 2. from a "script" developer perspective, where "*all the error > handling you need is to show a message, print a stack trace, and exit the > program*". > > There might be more angles to it, but Ben's sentiment rings a bell with my > own "customer" experience. > > So we can at least expect to have two "camps of judges" when it comes to > error handling improvement proposals. Some of the judges might be acutely > aware of the at least two different angles, but some of the comments not > least in this thread ("language designers" as kind of gods who must ignore > their customers, seriously?) seem to indicate that this isn't always the > case. Not least, I also fall into the less desirable category of the > ignoramus. > > So, maybe we should in the future always ask when it comes to a proposal: > which of the two perspectives does the proposal tackle? I'm under the > assumption that it might have been #2 in most of the proposals. The often > vivid negative responses should then be classified as belonging to #1 > and/or #2. If the proposal is about #2, then #1 proponents don't > contribute, but simply make life hard for the #2 customers of the Go > language. Same for the opposite combination. > > On Wednesday, August 2, 2023 at 6:11:01 PM UTC+2 DrGo wrote: > >> Fair enough … I understand that people have different styles >> >> On Wednesday, August 2, 2023 at 12:54:20 AM UTC-6 Brian Candler wrote: >> >>> FWIW, I'm in the "I like how it is now better than any other proposal so >>> far" camp; I think this happens as you get used to the Go way. Go is Go. >>> >>> The only thing I would consider is making *interface* types (only) >>> implicitly usable in a boolean context, e.g. >>> >>> if err { ... } >>> >>> However, I suppose people would ask "why not pointers? why not >>> channels?" etc. I'm not suggesting it should become like Python where >>> every non-zero value is treated as "true". Interface values are special, >>> and there's very little you can do with a nil interface (whereas for >>> example, a nil pointer can still have methods called on it). But this does >>> add a special case, and Go already has its share of surprises you have to >>> learn. >>> >>> On Tuesday, 1 August 2023 at 22:41:38 UTC+1 DrGo wrote: >>> >>>> Yes. Go is no longer the simple language it was. I suspect because of >>>> internal pressures within Google as evidenced by multiple innovations that >>>> seem to come from nowhere eg dir embedding and associated fs package that >>>> duplicated perfectly good ways of doing things. The module system while >>>> useful is quite complex. Generics and all the associated packages inflated >>>> the mental burden of learning and reading Go code significantly. And >>>> having >>>> the go 1 compatibility guarantee means that old stuff remains valid code >>>> and must be learned too. >>>> >>>> On Tuesday, August 1, 2023 at 2:59:07 PM UTC-6 Victor Giordano wrote: >>>> >>>>> Yeah.. I mean, the "idiom" `err != nil return` err is something of the >>>>> language. I complain about the boilerplate that idiom produces and that >>>>> is >>>>> fact fact (no one can deny it). >>>>> >>>>> You know, your approach implies making the language a little more >>>>> complicated as new ways to deal with errors appear. I do understand that >>>>> some folks provide some push back on the idea simply because there is >>>>> nothing wrong with the language right now regarding error handling. >>>>> >>>>> As I see things, the language was simple in their origins, but from >>>>> time to time they complicated a little more some things, for example >>>>> "what >>>>> about generics?" (are they really necessary?, I mean... I think using >>>>> interfaces provides all the genericity you may need). So I guess there is >>>>> room to make some changes and make the language easier. I would say that >>>>> both ways of handling errors are valid, the most important is to be as >>>>> simple as possible so you ensure that other people understand it. Like >>>>> Generics, you don't have to use them. So I would praise it for adding >>>>> another way, less repetitive. >>>>> >>>>> Also like to see how people react and what their opinions are. So far >>>>> what I read is just personal taste. >>>>> >>>>> >>>>> El mar, 1 ago 2023 a las 16:04, 'Luke Crook' via golang-nuts (< >>>>> golan...@googlegroups.com>) escribió: >>>>> >>>>>> And of course I forgot the "if" at the beginning of all those >>>>>> conditional. *sigh* >>>>>> >>>>>> -- >>>>>> 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/dRLR4hxxI8A/unsubscribe >>>>>> . >>>>>> To unsubscribe from this group and all its topics, send an email to >>>>>> golang-nuts...@googlegroups.com. >>>>>> >>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/golang-nuts/CADtPBF2%3DTNBorhCCamWGb29qkNkXxgFZ%2BmnhkOC0kG2sxzp%3DWw%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/d/msgid/golang-nuts/CADtPBF2%3DTNBorhCCamWGb29qkNkXxgFZ%2BmnhkOC0kG2sxzp%3DWw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> >>>>> >>>>> -- >>>>> V >>>>> >>>> -- 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/9a35c052-364a-4d20-8161-aa41a60fe140n%40googlegroups.com.
