But it's not a binary question. If you ask me
Would like go to have Maybe/Option type instead of val, err - then I can say yes. Would you like to have something such as Rust's Result instead of val, err - then I can say yes (even though I understand this may not be possible due to generics etc). But what is being asked here is would you like to have error handling and flow of control functionality baked together - and then my answer is no. I know from several years of experience writing both go and python/java that my go code is more stable than my python/java code is and the big part of it is the proper error handling. And yes go does have panic/recover - but I never use them for the same reasons I dislike exceptions. It's just really hard to reason about such jumps in logic especially in massively concurrent programs that go allows us to write. On Friday, July 5, 2019 at 10:30:43 PM UTC, andrey mirtchovski wrote: > > > So I was quiet on the topic then - I am not now. > > i guess you missed the point where I advocated for a new survey, well > advertised, where all the people who are fervent Go programmers but > somehow neglected to fill out the Go surveys for three years running > can cast their voice. "does go error handling need change: ◻️yes ◻️no > -- 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/3c8fc5c2-923f-46cd-965d-86889141dccb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
