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

321–330 of 425 posts

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

#321

Post by natefinch »

gigatexal wrote: post #262
wybiral wrote: post #238

Earlier quoted context omitted.

> Because it encourages nesting function calls, which is harder for a human to parse than separate statements across lines. I absolutely agree. Beyond the human parsing aspect it also makes commit changes easier to reason about and review. I want functionality to be limited per-line and view the ability to combine a lot of functionality into one line as a liability more than a benefit. Go's error handling isn't caref…

I thought it could lead to doing method chaining for a fluent like API which I find cleaner than how things work now.

I really dislike method chaining. I'd much rather have 5 lines than 5 chained methods. If that's too much to read, you can always encapsulate it in a well-named function.

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

#322

Post by lllr_finger »

tsimionescu wrote: post #319
nicoburns wrote: post #303

Earlier quoted context omitted.

But the issue with this is that it can be hard to know what all the possible error conditions are, and thus whether you have anything meaningful to do. Using Rust, which makes errors explicit like Go, has been eye-opening to me. My programs never crash because I've handled every error condition. No effort on my part. No tests needed.

Java also makes you handle every possible error condition, unless of course you chose to use an escape hatch. Rust allows the same. By the way, Go is much happier to crash than Java - for example, a simple array index out of range will cause a program crash in a typical Go program, where it would only cause a request failure in a typical Java program. Not sure how Rust handles this. Finally, choose that isn't tested…

Rust's use of Result is very different from try/catch and exceptions in Java, even if you opt-in to checked exceptions. The big difference is ergonomics and what patterns are used in underlying libraries - opting out of the idiomatic way in Rust feels wrong if you try doing it.

Rust handles your out of range scenario the same way Go does.

If any of this matters to you, the good news is that Kotlin's sealed classes (and soon, Java's sealed classes) allow you to easily implement your own Result-like sum type.

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

#323

Post by qwsxyh »

icebraining wrote: post #292
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…

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

That statement is still correct even in the context of the stdlib.

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

#324

Post by FreeFull »

tsimionescu wrote: post #319
nicoburns wrote: post #303

Earlier quoted context omitted.

But the issue with this is that it can be hard to know what all the possible error conditions are, and thus whether you have anything meaningful to do. Using Rust, which makes errors explicit like Go, has been eye-opening to me. My programs never crash because I've handled every error condition. No effort on my part. No tests needed.

Java also makes you handle every possible error condition, unless of course you chose to use an escape hatch. Rust allows the same. By the way, Go is much happier to crash than Java - for example, a simple array index out of range will cause a program crash in a typical Go program, where it would only cause a request failure in a typical Java program. Not sure how Rust handles this. Finally, choose that isn't tested…

Rust will also crash if you use the indexing operator and go out of bounds. For arrays, you can also use the .get(index) method which returns an Option instead of &T, so it doesn't have to crash. For most things, iterators get used instead of indexing anyway.

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

#325

Post by kadendogthing »

This reads like script kiddies who became professional programmers and just want things done how they've always been done.

Error handling in go is not concise, and calling it explicit is in insult to anyone with a modicum of abstract reasoning skills. Error handling in go is not explicit, it's verbose. Error handling in go is not concise, it's broad. Error handling in Go is not consistent, it's an exercise left up to diligent programmers.

As golang's code base grows, you're going to see this mistake play out over and over and over again.

Having a Result construct would have been great for go.

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

#326

Post by mplanchard »

bmurphy1976 wrote: post #176
UK-AL wrote: post #174

Earlier quoted context omitted.

In rust though, you dont have to handle errors all the time. You can just unwrap them, and crash when there's an error.

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.

I’ve written quite a bit of Rust, including an implementation of a collision-resistant UID algorithm and a static website generator. I’ve also written quite a few “git-er-done” scripts in the language as part of other projects (for example, a script to randomly generate linked data and write it to a couple of CSVs). At no point so far have I had to manually manage memory. As others have noted, this is what the borrow checker enables: you write code as though it were in a GC language, and the compiler handles inserting the allocations and deallocations.

Of course, you can manually manage memory in Rust, but it is almost never necessary for high level applications.

I’m not at all claiming it’s the best tool for every job (although I do think it’s great), just clarifying the point about memory management.

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

#327

Post by parasubvert »

voidfunc wrote: post #248
parasubvert wrote: post #236

Earlier quoted context omitted.

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.

Possibly, though Java these days is largely “Spring”.

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

#328

Post by parasubvert »

erik_seaberg wrote: post #291
parasubvert wrote: post #236

Earlier quoted context omitted.

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.

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.

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

#329

Post by parasubvert »

meruru wrote: post #255
voidfunc wrote: post #248

Earlier quoted context omitted.

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.

FWIW the essays I mentioned are from the early 2000s. Java's Cover is from 2001: http://www.paulgraham.com/javacover.html

That essay has proven to be astonishingly wrong. It’s 18 years later and I suspect he’d say the same things about Golang.

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

#330

Post by parasubvert »

KirinDave wrote: post #276
parasubvert wrote: post #236

Earlier quoted context omitted.

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.

Disclosure: I am not very impressed by Paul Graham as a programmer. However I think he came by his dislike honestly. When he was actively working, Java was really quite frustrating.

I have no doubt. I was one of the pro-Java people in 2001 (dating back to 1996). Language religious wars were really strong in those days, like there could only be one true language, everything else was a toy. The Java backers and community fought against that too aggressively relative to their own limitations.

Today each language ecosystem is much more self sustaining and has its own bizarre culture that looks frustrating to outsiders.

Post reply on HN