Fully agree.. I think my proposal is targeted primarily at that group although recognizing the strength and ability of group #1 to block any discussion
On Wednesday, August 2, 2023 at 1:30:00 PM UTC-6 TheDiveO wrote: > 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/3608fafe-26f9-4204-99ec-4db4f9691aean%40googlegroups.com.
