Declined Proposal: A built-in Go error check function, “try” • Hacker News Board

Re: Declined Proposal: A built-in Go error check function, “try”

#211

Post by apta » Wed, Jul 17, 2019, 3:39 AM UTC

wybiral wrote: post #202

mythz wrote: post #150

Earlier quoted context omitted.

> Go doesn't even really force you to check your errors, it just makes it harder to accidentally not check them. Like: I dislike it because it does the opposite, it makes it too easy to accidentally continue execution when there is an error: doThing(); // Error doOtherThing(); Which isn't possible with Exceptions. The only thing that would signal that error handling is missing is the absence of boilerplate to handle…

The nice thing about a statically typed language having standard golint and gofmt is that code is generally self documenting. So I wouldn't ever type that function call without seeing the function definition (in my editor or wherever else I found the API reference). But I agree, the fact that Go allows this is bad, imo. It would be better if you had to explicitly suppress errors, even with something like this "_ = do…

> So I wouldn't ever type that function call without seeing the function definition (in my editor or wherever else I found the API reference).

How often do you handle or explicitly ignore the error returned by fmt.Print? This is just proof that golang error handling is error prone.

Re: Declined Proposal: A built-in Go error check function, “try”

#212

Post by apta » Wed, Jul 17, 2019, 3:43 AM UTC

schrodinger wrote: post #132

KirinDave wrote: post #112

Earlier quoted context omitted.

> Exceptions feel super good, even as you're taking too many shortcuts and glossing over things. I'm not sure I follow this talk about "short cuts.". Exceptions provide stronger guarantees by default than multiple-value-bind and manual if statements. Your code fails closed as opposed to open. > Proper handling of the unhappy paths is often going to feel like a slog, because it often is complicated, and it's often a s…

go vet catches that scenario and won’t pass CI. You have to explicitly decide to ignore it by using an underscore for the err value and then you get just what you asked for.

fmt.Println says otherwise. That and it's possible to overwrite previous error variables, something that is not possible with exceptions.

Re: Declined Proposal: A built-in Go error check function, “try”

#213

Post by apta » Wed, Jul 17, 2019, 3:45 AM UTC

eikenberry wrote: post #170

KirinDave wrote: post #45

Earlier quoted context omitted.

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…

> I think the Golang community is going to find itself growing more slowly as folks increasingly realize other options offer similar benefits without the bad ergonomics. I'm curious about what you think these other options are? There are of course tons of languages and you can find just about any set of features you want, but the combination Go has along with the momentum, community, etc. it has means that there are…

> it has means that there are not many that can compare in its niche

Which is? "devops"? Otherwise, offerings on the JVM and .NET are strictly superior. And now with native compilation being available for both platforms, they will also be a better fit at devops than golang. Other alternatives include Rust.

Re: Declined Proposal: A built-in Go error check function, “try”

#214

Post by apta » Wed, Jul 17, 2019, 3:46 AM UTC

weberc2 wrote: post #164

KirinDave wrote: post #45

Earlier quoted context omitted.

> Do I particularly like managing errors that way? No, but I do think that it improves the transparency and quality of a lot of Go projects. So long as we can all agree that it feels super bad, I guess this is fine. But it does sort of mean that Golang approaches the Java world back with checked exceptions where principle trumped ergonomics. That lead to a world where folks felt "forced" to use Java, and that's a sti…

I understand what you mean by “bad ergonomics”, but I think of those things as “ergonomics in the small”. You end up writing for loops and error checks. It’s verbose but not complex, and it’s all very localized. Further, people get really hung up on these small language issues and miss go’s killer features: simplicity and consistency. Go is a small, simple language with few surprises. No guesswork about which feature…

golang's "simplicity" (i.e. unexpressivity and weak modeling ability) translate into complexity in real world code bases. There's no way around it.

Re: Declined Proposal: A built-in Go error check function, “try”

#215

Post by crimsonalucard » Wed, Jul 17, 2019, 3:51 AM UTC

millstone wrote: post #194

crimsonalucard wrote: post #86

Earlier quoted context omitted.

The maybe monad is the best solution for this. Usually to support this the language needs Enum support and a proper type system neither of which golang has. So I'm ok with the developers just baking in syntax for an error monad with specific sugar for extracting the value or handling an error.

Why is a monad the “best” solution? Best according to what criteria? Special purpose syntax can buy you a lot more. For example Swift’s try makes it obvious which statements contain error handling without burdening each expression.

Ok let me tell you the criteria. There are two.

First: The monad allows for composition of functions. Returning two values does not. It breaks the flow of a function pipeline and forces you to handle every error in the same way.

Second: Extracting the value via pattern matching guarantees that the error will either be handled or used correctly. This is a way to 100% guarantee that there are No runtime errors. That's right. Using the error monad with pattern matching makes it so that there is zero room for runtime errors.

Why create a language that has runtime errors? Create a language that forces you to handle all possible runtime errors before it even compiles.

According the criteria of safety, zero runtime errors, and expressivity via composition the monad is the Best solution. There is literally no other way of error handling that I know of that can catch runtime errors at compile time.

I know you tried to flip my statement on it's head by using the term "criteria" as if there are many many different criteria for "best." And you are right, programming is an opinionated thing. However, ZERO runtime errors is a too powerful of a feature to assign to a specific criteria. Such a feature is so powerful, it should be part of EVERY criteria.

If you don't understand completely what I mean by "composition" or how pattern matching and a maybe monad can guarantee a runtime error will NEVER occur, ask me to elucidate, I'm happy to clarify.

Re: Declined Proposal: A built-in Go error check function, “try”

#216

Post by apta » Wed, Jul 17, 2019, 3:52 AM UTC

comex wrote: post #201

bmurphy1976 wrote: post #125

Earlier quoted context omitted.

And that's totally fine. I don't always want to be fighting with monads. If I did I'd write Haskell code. Go is the quick and dirty git-er-done tool that provides quite a bit more performance and type safety than Python, but maintains some of the development speed/ergonomics. Here's the thing, some of us don't want Rust. It looks great! It's perfectly awesome for it's primary domain (i.e. re-implementing critical por…

Wait, what? The OP said that they like Go’s error handling because it forces them to think about errors and make their code more robust. You’re saying you like Go as a “quick and dirty git-er-done tool”. Those are opposite viewpoints! For your use case, it seems like something like try() being added to Go would be a benefit, since it would make it easier to write “quick and dirty” code that still provides at least ba…

I see many golang users just parrot what golang authors say, without having any evidence about those claims. Things like "golang is designed for development in the large", or "golang forces you to think about errors" or that the way it handles errors is robust, all claims that have nothing to support them (on the contrary, reality is the opposite of those claims).

Re: Declined Proposal: A built-in Go error check function, “try”

#217

Post by bmurphy1976 » Wed, Jul 17, 2019, 3:52 AM UTC

comex wrote: post #201

bmurphy1976 wrote: post #125

Earlier quoted context omitted.

And that's totally fine. I don't always want to be fighting with monads. If I did I'd write Haskell code. Go is the quick and dirty git-er-done tool that provides quite a bit more performance and type safety than Python, but maintains some of the development speed/ergonomics. Here's the thing, some of us don't want Rust. It looks great! It's perfectly awesome for it's primary domain (i.e. re-implementing critical por…

Wait, what? The OP said that they like Go’s error handling because it forces them to think about errors and make their code more robust. You’re saying you like Go as a “quick and dirty git-er-done tool”. Those are opposite viewpoints! For your use case, it seems like something like try() being added to Go would be a benefit, since it would make it easier to write “quick and dirty” code that still provides at least ba…

I mostly agree with the op. I was replying to pcwalton's comment, or more specifically those who would solve every problem with a monadic straight jacket. I don't agree that that is always the best way to handle errors. There are tradeoffs involved that are hard to define but really do make a difference. I think Go finds a sweet spot thay has been ignored by the academic community. Hence my labeling of Go's error handling as conceptually imperfect.

Re: Declined Proposal: A built-in Go error check function, “try”

#218

Post by apta » Wed, Jul 17, 2019, 3:58 AM UTC

alexbanks wrote: post #209

This thread is rife with "Go should have Try because I want Try" that also seem to be made by developers that do not write Go. It seems confusing to me that voices generally involved from Go are so demanding of its maintainers. Curious, are there full-time (or at least Primary) Go developers that are upset by the lack of Try?

> 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.

Re: Declined Proposal: A built-in Go error check function, “try”

#219

Post by EdwardDiego » Wed, Jul 17, 2019, 3:59 AM UTC

thomascgalvin wrote: post #152

EdwardDiego wrote: post #137

Earlier quoted context omitted.

My most hated checked exception is the IOException Jackson throws when parsing JSON I can guarantee to be valid JSON. I could live with a runtime exception, or perhaps an API that differentiates parsing "potentially not-parseable JSON" and "JSON I can vouch for".

I usually end up writing a bunch of utility methods for stuff like this. Typically it's called something like `parseQuietly`, and it just Pokemons any exceptions.

I am stealing Pokemon as a verb, my thanks.

Re: Declined Proposal: A built-in Go error check function, “try”

#220

Post by apta » Wed, Jul 17, 2019, 4:02 AM UTC

z0r wrote: post #38

CraftThatBlock wrote: post #24

Earlier quoted context omitted.

Anti-cleverness is what makes Go great. Go code is simple, and it is easy to read/understand. It's a feature of the language

Go code is all about being able to see the trees, forget about the forest. Go programs are rarely easy to read or understand unless they are written by exceptionally talented developers in my experience.

Agreed. Because golang is "simple", the actual code base becomes a mess, littered with 10 line functions that are basically map/filter/etc. calls, which can be written on a single line in a proper modern language. The majority of golang code bases I've seen are much more difficult to follow compared to if they had been written in something like Java or C#.