I don't think it has anything to do with motivation, Mike. The problem I see is that there is no good enough solution that offers a substantial benefit over the current approach. Many error handling proposals involve rearranging the code with a few line savings, and sometimes at the cost of readability. Note that there is no perfect solution to error handling to date. Even the conventional try-catch-finally has its own problems. I appreciate the Go Team's restraint in this matter.
On Monday, July 3, 2023 at 9:42:02 AM UTC+7 Mike Schinkel wrote: > On Wednesday, June 28, 2023 at 1:30:41 PM UTC-4 Sven Anderson wrote: > > I think for what you want to do you don't need any language extension. > > > On Sunday, July 2, 2023 at 2:04:29 PM UTC-4 Harri L wrote: > > *The sample block below is what we can have without any language updates.* > > > Many times when people ask for new language features it is possible to > simulate what is being requested via some combination of convention and/or > reusable package(s). > > But sadly, at least in my experience, most teams are only motivated to > continue the approach they chose initially and not interested in changing > to a new non-standard approach, and this is the case for almost anything > proposed as *"something we can do today"* unless it has already > established itself as a defacto-standard way to approach the problem. > > Although some conventions and some packages come close to achieving > defacto-standard status — Cobra for CLI is the closest one I can think of > for Go even though it is far from defacto — the use of most conventions > and/or packages required a motivated team or at least a motivated > individual. > > The simple fact is even if the core Go team adds a new feature for error > handling, many will still not embrace it, at least not for a while. But if > there is any chance a motivated individual has to get an unmotivated team > to adopt a new approach, it almost has to be an approach advocated for by > the core Go team, and with new features that make that approach possible. > > So while it may be great for motivated individuals and the rarer motivated > teams to hear about how we can do things today without the new language > features we are requesting — and the developer of the package that enables > it is certainly motivated — there is little chance a *"can do today"* > approach > will address the reason people ask for a new language feature. And > especially for error handling improvements, which is near the top of the > things people want to see improved in Go, per the Q1 2023 Go Developer > Survey[1]. > > #fwiw > > -Mike > > [1] Go Developer Survey 2023 Q1 Results - The Go Programming Language > (golang.org) <https://tip.golang.org/blog/survey2023-q1-results> > -- 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/3f93f16f-6d43-492d-8961-400be98ef707n%40googlegroups.com.
