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

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

#161

Post by voidfunc » Wed, Jul 17, 2019, 2:16 AM UTC

inlined wrote: post #47

sagichmal wrote: post #39

Earlier quoted context omitted.

Go error handing _is_ fundamentally fine the way it is. That is, the verbosity would certainly benefit from some sugar, but the semantics -- errors managed by separate expressions/blocks immediately adjacent to the error-generating code -- is fundamental to the language, and one of its great strengths.

I repeatedly tell people that Go takes twice as long to write and half as long to debug. Unless you write perfect code on the first try, the trade off is probably worth it.

Today I spent two hours tracking down why a nil pointer was occurring in my code. Turns out I forgot to pass it along to the struct initializer through one of the damn factory functions I need to create so I can hide internal fields properly... this was nested code in a framework.

Tell me again how easy it is to debug Go. In other languages the compiler can just tell me in _seconds_ that I done fucked up.

If you response includes "You're doing it wrong if you have deeply nested framework code" then you can rightly fuck right off too.

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

#162

Post by qtplatypus » Wed, Jul 17, 2019, 2:16 AM UTC

drivebyops wrote: post #5

Great that they listened to the community

Its a pity that they listened to the members of the community that was opposed to try. I was a massive fan of try or anything else that would prevent me writing the same boilerplate code.

I feel some in the go community have become convinced that the “go way” is to write the same code over and over again.

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

#163

Post by voidfunc » Wed, Jul 17, 2019, 2:17 AM UTC

It's rather disappointing that Go has managed to bungle error handling so badly in a language only a handful of years old.

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

#164

Post by weberc2 » Wed, Jul 17, 2019, 2:20 AM UTC

KirinDave wrote: post #45

wybiral wrote: post #33

This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Do I particularly like managing errors that way? No, but I do think that it improves the transparency and qual…

> 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 subsets to use. But simplicity and consistency are themes that runs throughout the developer experience. Everyone uses gofmt so everyone’s style is the same. The standard library comes with a testing library and everyone uses it. Also, there is only one test runner, it comes with the toolchain, and you can run it on any project without special project knowledge. There is only one build system and it doesn’t make you learn a new project configuration DSL to use it, nor does it require anyone to have a working knowledge of compilers or linkers. You just run “go build” and you get a binary, and it works on almost every project (some larger projects have FFI or code generation steps). Static linking is the default. You don’t have to configure a CI job to package your libraries and push to a package registry. Nor do you have to make documentation packages or operate a webserver to serve your docs (or push to a hosted server). And the documentation tooling doesn’t require you to learn a custom documentation markup language—it’s just comments. The GC has only a couple of tuning knobs. There is no dichotomy between sync libraries and async libraries (e.g., flask vs aiohttp) nor are there questions about which coroutine / thread / async frameworks to use. I could go on and on and on, but I think I’ve made my point. I think these are the features that people like about Go and are going to continue to drive its growth until other languages wise up.

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

#165

Post by wybiral » Wed, Jul 17, 2019, 2:21 AM UTC

KirinDave wrote: post #157

wybiral wrote: post #117

Earlier quoted context omitted.

> any code search reveals that "if err != nil { return err }" is everywhere Code searches in languages with exceptions tend to wrap the tryblocks around massive portions of code instead of the individual function calls to the point that you have a top level doing: try: ...program here... except: print('¯\_(ツ)_/¯')

... I could do this with Golang too, couldn't I?

On the opposite end of the spectrum, yes, as they pointed out you can just return all of the err's up the stack.

I wasn't saying that Go's approach solves this, just that it's not a problem unique to Go.

And in the case of Go it's painfully obvious that you're ignoring all of those errors whereas in other languages you can't always tell, visually, that they're being ignored because of the magic of exceptions.

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

#166

Post by pcwalton » Wed, Jul 17, 2019, 2:22 AM UTC

sagichmal wrote: post #144

pcwalton wrote: post #106

Earlier quoted context omitted.

> But it results in still less cumbersome code, since you only need scoping for the error handling portions.) There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks. There is a meaningful difference in cumbersomeness between what Go has today and "try foo(try bar())". Which is why it's so unfortunate that the community killed the try proposal. > But forgetting…

> There isn't a meaningful difference in cumbersomeness between having two try-catch blocks and two if-err blocks As demonstrated by the sibling comment to mine, this is wrong. > In practice programs written in languages with [exceptions] tend to have better error diagnostics than Go programs. Anyone who's spent time on teams working in exception-oriented languages like C++ or Python knows this to be clearly false. >…

I'm not saying you should use Rust! I'm saying that Go should add try.

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

#167

Post by djur » Wed, Jul 17, 2019, 2:23 AM UTC

Thaxll wrote: post #154

KirinDave wrote: post #120

Earlier quoted context omitted.

I guess then I have to ask, why would try() make that worse? Because I can't stand Golang error handling. It's repetitive, it's error prone, and other language features interact with it so that when you make a mistake it can be as hard as a double free to track down where the erroneous default value was introduced. On the other hand, using Rust, Ocaml, F# or Haskell I understand how my code composed and I can be conf…

How returning (val, err) is error prone? It's verbose but it's clear and definitely not error prone. I spent so much time working with Java and useless giant stacktraces or with Python and people not knowing what to do inside a try / except.

Repetition and verbosity in a language can create errors in at least two ways. First, by the developer losing track of which error case is which (and/or copy-pasting error-handling logic) and doing the wrong thing in the error case. Second, by reviewers who have become trained to notice and gloss over error-handling boilerplate not noticing when there's something wrong with a particular case.

Concise languages can be more challenging to read because you have to understand more about each symbol/word in the language. But verbose languages can be more challenging to comprehend because there's a lot of symbols which don't signify anything.

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

#168

Post by poweroftrue » Wed, Jul 17, 2019, 2:24 AM UTC

Just try writing three Go programs with error handling, then, try other languages!

I was pissed at first. However, now I cannot code in any language without overusing try and being scared of each line.

Using Go's error handling is actually making your code smarter, I mean, you don't want your code to break with a weird message because of something stupid.

The simplest example is adding a default-path whenever I'm reading a file, Go's error handling reminds me of what to do if this file doesn't exist! Or cannot read etc.

Don't take my word for it, Go ;) try it.

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

#169

Post by bmurphy1976 » Wed, Jul 17, 2019, 2:25 AM UTC

qtplatypus wrote: post #162

drivebyops wrote: post #5

Great that they listened to the community

Its a pity that they listened to the members of the community that was opposed to try. I was a massive fan of try or anything else that would prevent me writing the same boilerplate code. I feel some in the go community have become convinced that the “go way” is to write the same code over and over again.

I think try is jumping the gun.

Implementing try now is splitting the community and introducing what will likely be new technical debt. It doesn't fundamentally change things, it only makes the language more complicated in a way that's both weird* and likely to become obsolete once generics are a thing.

They should focus on xerrors for now and wait until generics are implemented and try again.

* weird as in there are no macros and there's no other language construct that behaves like this so it's a totally unique and new thing for Go

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

#170

Post by eikenberry » Wed, Jul 17, 2019, 2:29 AM UTC

KirinDave wrote: post #45

wybiral wrote: post #33

This hits at something fundamental about Go, which is what I like the most about it... It's a language intended to have few primitives with an emphasis on code being transparent and errors being values, requiring you to think about what they might be at each point as you're forced to carry them up the chain. Do I particularly like managing errors that way? No, but I do think that it improves the transparency and qual…

> 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 not many that can compare in its niche.

Ignoring the language/semantics (ie. the bad ergonomics) and just focusing on the external aspects. Which languages targets the same niche that have the "similar benefits" of fast compile times, static builds, great tooling, good/improving libraries, easy deployment, and mainstream backing/acceptance?