Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

241–250 of 425 posts

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

#241

Post by AsyncAwait »

millstone wrote: post #206
sagichmal wrote: post #52

Earlier quoted context omitted.

That feels about right, but missing the most important measure, IMO, which is it takes 10-100x less time to read and understand a new codebase.

Disagree hard! a = append(a[:i], a[i+1:]...) That’s the recommended implementation of erase(). After this, is the original object referred to by ‘a’ modified? How can you tell? Let’s pop from a stack: x, a = a[len(a)-1], a[:len(a)-1] Did you read that 100x faster than ‘a.pop()’? Now this: a = append(a[:i], append(make([]T, j), a[i:]...)...) This is an operation called “expand.” What does it do? It is an honest questi…

The number of times I had to do this in practice over tens of thousands of lines of production Go code is about 3.

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

#242

Post by didibus »

gridlockd wrote: post #124
pcwalton wrote: post #78

I suspected this was coming, and it's unfortunate. If Go had implemented try, then in a year everyone would be happy using it and the controversy would have died down. I've seen this happen before. Unfortunately, the community that has sprung up around Go is more or less opposed to new language features on principle.

The controversy may have died down, but the impact on code written would have been permanent. There's a lot of value to there being "one way to do things", even when it's not the best way from any particular point of view. Go holds this principle higher than most other languages and I think that should be either embraced, or one should look elsewhere - and I'm saying that as someone who "looked elsewhere".

Agreed, no one is forced to use Go. I think it is refreshing to see a language like Go. You don't want all languages to asymptotically approach each other in features. We need diversity in our languages, that way you have flavors to choose from.

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

#243

Post by wolco »

kartickv wrote: post #197
djur wrote: post #167

Earlier quoted context omitted.

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…

Interesting perspective. Are you expressing an opinion about "explicit is better than implicit", or is your point on a different axis? I suppose concise / implicit is fine when the thing that's being hidden can't go wrong, like in: [i * 2 for i in 1...10] The loop counter increment logic can't possibly go wrong, so it's fine to not think about it. Regarding error-handling, don't you want to think about? If you're cal…

you have 'catch' to handle those cases. Try and catch are easy to notice when scanning the codebase.

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

#244

Post by thatswrong0 »

mcbits wrote: post #126
thatswrong0 wrote: post #110

Earlier quoted context omitted.

I wish gofmt would let you set a desired line length and break it for you.. prettier has me spoiled in that regard

If a tool is going to enforce line length limits, I'd rather have it spit a warning/error than silently try to guess a good place to break the line automatically. Otherwise, an editor tool that soft-wraps long lines at the (often poorly) guessed location without touching the code would be better.

But that’s the thing about prettier - it wraps exceptionally well because it actually parses the AST. I never think about how I space my JavaScript anymore because it always does it correctly.. it’s one less thing to get in my way when I code

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

#245

Post by takeda »

natefinch wrote: post #98
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…

Literally the first non-trivial code I wrote in go (running a bunch of goroutines to download a ton of files from a website in parallel)... I knew exactly where and how things could fail and where things were failing just by looking at the code. Coming from C++ and C# and Python, there was no comparison. I had never been so confident in the code I'd written, even though I was a newbie at Go and a veteran of the other…

This is interesting, I didn't feel that with go I understand my code better, but I also don't think I was lost in other languages.

My impression of go, is that it is very boring to program in it, and some decisions weren't thought well. For example if you use anything else for numbers than int, int64 or float64 you will have very bad time. Lack of generics forces you to duplicate your code, duplicating increases chances of errors and make it harder to fix bugs. The errors are passed as values, but then you need to use different return value to pass them, defeating the whole point of having that. On top of that the language is very rigid.

I'm wondering if introducing macros could solve a lot of those issues.

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

#246

Post by asplake »

wvenable wrote: post #198
ben509 wrote: post #184

Earlier quoted context omitted.

I thought extending _throws_ with an _as_ clause would make it far more manageable: void foobar() rethrows IOException as AppException rethrows FooError, BarError as WtfError { Being able to express that a bunch of internal exceptions should be wrapped in an application exception would save a ton of boilerplate. The exception syntax itself is also clunky. If you have a complex expression, you have to extract it and a…

> Being able to express that a bunch of internal exceptions should be wrapped in an application exception would save a ton of boilerplate. It would but I think it's the wrong approach -- you're actively changing the error information that really provides no additional value except to make the type-checker happy because the alternative is too verbose.

Doesn’t wrapping usually mean adding (semantic) information without changing the original?

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

#247

Post by voidfunc »

sagichmal wrote: post #227
voidfunc wrote: post #161

Earlier quoted context omitted.

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 resp…

Why are you using factory functions? Why are you trying to hide internal fields? The description of what you have to do is setting off some warning bells. It's certainly possible to write difficult-to-maintain code in any language. > If you response includes "You're doing it wrong if you have deeply nested framework code" then you can rightly fuck right off too. I mean, can you point me to an example? Absent more con…

Because we don't want to export internal fields of structures in our API or we need to perform initialization logic before considering the structure ready for use?

That's a pretty common use case but ignore that for a moment and just distill the problem down to it is possible to have null pointer issues in Go code.

Another example eith sufficient use of goroutines and channels it gets really tricky to debug something when a receiving channel blocks because something isn't sending.

There's plenty more. I don't find Go any simpler to debug than Java, Kotlin, Rust, or Python and in many cases it is significantly more difficult because you're constantly fighting the type system or working through huge amounts of boilerplate.

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

#248

Post by voidfunc »

parasubvert wrote: post #236
meruru wrote: post #180

Earlier quoted context omitted.

pg wrote a bunch of really good essays about Java vs Python vs Lisp and how those were perceived by programmers. I always remember them when I see Go being compared to Java while still being liked by Hackers. I wonder what he would write about this phenomenon.

pg has a blind spot wrt Java. Lots of hackers liked (and still like) Java ecosystem (see Kotlin for more recent fun). like lisp hackers, they hung out on their own and didn't mingle.

This, but also I suspect a lot of people that claim to dislike Java are tainted by it's framework heavy ecosystem especially early-mid 2000s.

The language itself is fairly clean and very pragmatic.

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

#249

Post by jpittis »

Thaxll wrote: post #205
jpittis wrote: post #188

Earlier quoted context omitted.

Having unwrap() in your Rust code is like littering your code base with panic(). It’s not appropriate to use in most production code, but is convenient in prototypes, examples and tests. Your example re Go errors is incorrect. The go compiler allows you to ignore errors in returns without any compiler error. For example err := doThingThatErrs() and doThingThatErrs() are both valid Go code.

My example is correct I explained all of that, multi values -> need to omit, single value can ignore everything.

Yup. I misspoke. We’re both right.

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

#250

Post by badtuple »

AsyncAwait wrote: post #241
millstone wrote: post #206

Earlier quoted context omitted.

Disagree hard! a = append(a[:i], a[i+1:]...) That’s the recommended implementation of erase(). After this, is the original object referred to by ‘a’ modified? How can you tell? Let’s pop from a stack: x, a = a[len(a)-1], a[:len(a)-1] Did you read that 100x faster than ‘a.pop()’? Now this: a = append(a[:i], append(make([]T, j), a[i:]...)...) This is an operation called “expand.” What does it do? It is an honest questi…

The number of times I had to do this in practice over tens of thousands of lines of production Go code is about 3.

That surprises me. I have to manipulate slices all the time! Popping an item from a slice, reversing one, or clearing one without allocation in a hotspot is super common for me.

I've used Go professionally for 6 years and love it, so the patterns are ingrained in my head and don't bother me. But it seems pretty clear that it's much more arcane than alternatives.

Post reply on HN