> Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try?

I use golang at an employer. error handling in golang is verbose, error prone, distracting, and difficult to make sense of when there is actually an error (composing). I've seen on several occasions now errors being mishandled (either dropped by accident, or by overwriting already existing error variables in the same scope). These issues don't happen with exceptions.

It's interesting that as a full time Go developer myself, my experience has been very different about the points you have mentioned. I personally think verbosity is good. For one, lack of verbosity catches my attention. If I am reviewing code that looks like some part of it is ignoring the error, I would try to find a reason about that error check exclusion. This also prevents errors being dropped by accident.

About overwriting, again this has never been a problem for me (as far as I can recall). Error values are very much localised in almost all Go code I have seen and written. If a function returns an error it is either immediately acted upon or returned by the caller. As such, any overwriting done at a later stage is more or less for convenience sake.

> This also prevents errors being dropped by accident.

Instead of designing a language that prevents errors from being dropped by accident, hire a bunch of literal gophers to search your codebase for inverbosity. Good plan will work 10/10 times.

And this is what you could use to write up an experience report concrete, as in real, actual happened events. Here is what we have faced in production type thing. The maintainers want that. They don't want hypotheticals no matter how logical or obvious they might be. These feed improvements. I'd encourage you to write that up.

Have you contributed to the discussion about `try` in the GitHub issue tracker?

I am a full time developer in go. I feel the lack of good error handling every time I write a function call and then have to use the same if statement to check its result.

Have you contributed to the discussion about `try` in the GitHub issue tracker?

I write a lot of go in the context of web(micro)services. In stateless services it’s almost always better to bubble up the error and let the caller retry. So I hate the current error handling in this context, it’s a verbosity tax with no value add. Am ambliviant about try though

Have you contributed to the discussion about `try` in the GitHub issue tracker?

> Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try?

I am a full-time Go developer. Error handling in Go is miserable. `try` would have made it slightly less miserable.

Have you contributed to the discussion about `try` in the GitHub issue tracker?