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

291–300 of 425 posts

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

#291

Post by erik_seaberg »

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.

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.

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

#292

Post by icebraining »

sagichmal wrote: post #275
tsimionescu wrote: post #274

Earlier quoted context omitted.

The difference with catch blocks in Java, C++ or Python is that you only need to write them when you actually have something g meaningful to do. If you only need to propagate the error or cleanup resources then propagate the error, then all you would write is... Nothing. And cleanup+propagation is by far the most common error handling strategy. In Java and Python exceptions even add context for you automatically to h…

One foundational principle of Go is that the sad path is at least as important, and maybe more important, than the happy path. The best Go programmers I know write the sad path of their programs first, and then backfill the happy-path logic. So: > you only need to write [error checking] when you actually have something meaningful to do. Although it's the subject of a lot of ridicule, `if err != nil { return err }` is…

> `if err != nil { return err }` is actually bad Go code, and not often written by good Go programmers.

Like the people who wrote the Go stdlib? Because that's filled with those - just look at the net/* packages.

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

#293

Post by mattxxx »

I think this is the right decision. Error-handling the go-way focuses on whether a single operation failed, rather than how a set of operations failed.

In Python or Java, you see a lot of try-catches around blocks of code, which can obfuscate where the source of the error is, despite having particular handling for the type of error.

For systems code, I mostly care about whether something failed... like: - Was the socket opened? - Was the file created? - etc.

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

#294

Post by abhink »

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…

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.

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

#295

Post by ithkuil »

VMG wrote: post #289
sagichmal wrote: post #275

Earlier quoted context omitted.

One foundational principle of Go is that the sad path is at least as important, and maybe more important, than the happy path. The best Go programmers I know write the sad path of their programs first, and then backfill the happy-path logic. So: > you only need to write [error checking] when you actually have something meaningful to do. Although it's the subject of a lot of ridicule, `if err != nil { return err }` is…

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

yeah; we're getting there though, see https://github.com/golang/go/wiki/ErrorValueFAQ

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

#296

Post by 0815test »

jzoch wrote: post #278
bmurphy1976 wrote: post #176

Earlier quoted context omitted.

It's not just that though, GC is also a big part of the equation. I stopped manually managing memory 20 years ago. I'm not interested in going back to that. I get that certain aspects of Rust make that easier (and certainly safer) but I'm not working in a domain where the performance gains of ditching GC matter.

You are hardly managing memory in rust...reference allocation is practically garbage collection and feels as such in rust.

Reference allocation _is_ essentially equivalent to garbage collection, the one thing it doesn't deal with correctly is reference cycles. Which are inherently unlikely if you spend the time and effort to organize your code properly. (The Rust community is also working on cycle-aware reference collection, e.g. https://github.com/lopopolo/ferrocarril/blob/master/cactusre... but this will always come with some drawbacks.)

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

#297

Post by repolfx »

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…

There are competitors with just as much momentum and community, if not more.

Kotlin is now the official language of Android, and is being very rapidly picked up all across the Java ecosystem. Oh but it also compiles to JavaScript and LLVM native binaries if you don't want the JVM.

The syntax and ergonomics of Kotlin are great. Really nice language. The compiler is also very fast, just as fast as Go's I believe. It does incremental compilation and all the mod cons.

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

#298

Post by 0815test »

tempsolution wrote: post #55
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…

You can't compare it to Java checked exceptions. Java checked exceptions are one of those billion dollar "mistakes". It is the single worst thing in Java for me. Checked exceptions add nothing and break almost everything around clean design & code. For that comparison to work, java would have needed to only have checked exceptions, with some added language features to deal with them cleanly, and then it might actuall…

The irony there is that Result is entirely equivalent to "checked" exception specifications. The quality of surrounding support to "deal with [error states] cleanly" in one vs. the other makes all the difference.

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

#299

Post by anonymoushn »

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're using defer to close the temp file either way.

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

#300

Post by repolfx »

eikenberry wrote: post #290
apta wrote: post #213

Earlier quoted context omitted.

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

I would say the niche is basically clouds systems programming and general server side apps. JVM based language can't compare due to the JVM. The last thing you want for that type of programming is a huge, complex virtual machine to worry about. That plus memory issues, slow compiles, complex deployments makes it not really in the running. The .net based languages are a bit more interesting, but they have a _lot_ of g…

The last think you want for general server side programming and cloud systems programming is Java? Because of the JVM?

You should probably tell Google and Amazon that. Both very heavy users of Java on the server, despite Go. In fact the server space is where Java is most dominant!

The JVM is not actually complicated to use, especially not in the latest versions. It has the same number of 'default knobs' (that you should probably tweak in production) as Go does, but they're simpler to understand, for instance, Go requires you to control GC overhead by specifying "heap overhead" whereas Java just lets you specify a pause time goal directly, which is what you actually care about.

As for slow compiles, where did you get that idea? Java is extremely fast to compile. You can compile hundreds of thousands of lines of code and start executing them in seconds. I wonder to what extent you really used the ecosystem at all, with comments like that.

Post reply on HN