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

331–340 of 425 posts

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

#331

Post by inlined »

sagichmal wrote: post #223
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…

Slice operations are deliberately verbose in this way so as not to hide the cost of allocation that goes along with them. They are not common in code, but they do make good strawmen when you want to counter general points with specific ones.

Aligned incentives? Making a “simple” operation as hard to write as it will be on the machine.

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

#332

Post by checktheorder »

parasubvert wrote: post #328
erik_seaberg wrote: post #291

Earlier quoted context omitted.

Java without generics and lambdas was terrible. Yegge's https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo... was spot on because the only way to pass an expression or a block of statements was to wrap it in an object and give it to something that knows which method to call.

Java’s success was built in those days though. Personally I liked the language just fine without those features, Java generics in particular make code a lot less readable IMO. This is partly why I like Golang so much, they’ve been focusing on readability. I will agree that Lambdas are better than anonymous inner classes.

>This is partly why I like Golang so much, they’ve been focusing on readability.

Speaking as someone who's just returned to coding after a two-decade absence (mostly for fun), this is the #1 thing I love about Golang. I can actually read code from very experienced and skilled developers and understand what they'd written. And yet the language itself is highly capable - I don't feel like I'm learning some "beginner" language, but a "real" one that I can use for practical purposes.

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

#333

Post by skywhopper »

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…

We don't all agree that it feels super bad. I think you are completely wrong on the ergonomics. Go's error handling looks ugly to people used to languages that try to _hide_ error states, but it's so much easier to work when you are unfamiliar with the codebase or when it's been a few months since you last touched the code. Clarity of unfamiliar code is part of language ergonomics as well.

I'm not sure I follow your argument about Go "approaching" checked-exceptions in Java. Nothing is being forced on you. Go has worked the same way for a decade now. There is a lot of hugely successful software written in Go. In all that time, errors have worked the same way. In terms of choosing principles over ergonomics, in fact the Go committee chose ergonomics over the mistaken principle that "explicit error checking is so ugly and onerous that it's worth adding magic behavior and removing clarity".

In any case, no one is arguing we shouldn't or couldn't improve Go's ergonomics. Rather, the conclusion from people who work with Go every day and are happy with the tradeoffs for their particular projects was that this specific change would make more things worse than it made better.

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

#334

Post by philwelch »

stcredzero wrote: post #92
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…

So long as we can all agree that it feels super bad, I guess this is fine Exceptions feel super good, even as you're taking too many shortcuts and glossing over things. Proper handling of the unhappy paths is often going to feel like a slog, because it often is complicated, and it's often a slog. Glossing over error handling in golang can feel bad exactly when it should.

In some contexts, exceptions are just cleaner and easier. If I’m writing a web backend, my error handling is going to almost always be, “stop trying to do things and generate a 4xx/5xx response”. Throwing an exception from anywhere and then handling it at the top of the request handling does that without having to tediously carry errors all the way up the call stack.

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

#335

Post by EmpirePhoenix »

Cthulhu_ wrote: post #318
VMG wrote: post #289

Earlier quoted context omitted.

> Errors in Go are, at a minimum, annotated with contextual information before being returned. What surprised me when I last wrote Go was that there was no out-of-the-box solution to adding a stack trace to the error.

Does anyone know if this was a conscious decision? I mean IIRC in Java you're generally discouraged from throwing errors for control flow because creating the stack trace is a relatively heavy process. In Go this is of less concern and returning an error is pretty normal for control flow (as in errors are expected, not exceptional), and you shouldn't have to worry that an error path would be 100x as expensive as a no…

Java allows since ~a decade time to omit the generation of stacktraces, for exactly such cases

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

#336

Post by peteretep »

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…

> I knew exactly where and how things could fail and where things were failing just by looking at the code

Don't you just mean you knew where fatal exceptions could be raised? That's substantially different from "fail".

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

#337

Post by break_r »

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 am a full-time Go developer. Error handling in Go is miserable. `try` would have made it slightly less miserable.

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

#339

Post by codr7 »

akvadrako wrote: post #302
voidfunc wrote: post #163

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

Probably something about ideology overriding practicality. Personally I find go error handling okay but that’s because I exclusively use panic().

Just don't let any true believers near it or they'll tear you a new one.

I've published plenty of Go code with a panic() here or there to handle fatal issues, and there's never a shortage of ignorant fools dropping in to lecture me.

If I'm not supposed to use it, why is it even in there? To tempt me? That would fit with the glorification of pain and boredom, I guess.

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

#340

Post by sethammons »

apta wrote: post #218
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…

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.
Post reply on HN