Go 1.8 Release Notes

Re:Go 1.8 Release Notes by curun1r on Thursday February 16, 2017 @04:50PM (#13663842)

I agree wholeheartedly. Also of note, the combinators Rust offers on Option/Result make it possible to chain multiple operations that could fail and then check for the first error that occurred. In Go, you have to check each potential error immediately after it's potential return. This allows Rust to be just as clear as Go while being more concise and enforcing at compile-time that errors are handled. Propagating errors out of a function is also easier given try!/?.

I really don't see a downside of Rust's approach compared to Go's after having programmed in both. But, then again, Rust's approach requires generics and I know Go's team doesn't want to go in that direction.

[ Parent | on HN ]

Re:Go 1.8 Release Notes by iand on Thursday February 16, 2017 @08:24PM (#13665170)

Chaining and failing on first error is only useful for the most trivial of error situations. Non toy programs handle errors with retry strategies, alternate algorithms and fallbacks which may all be contextual.

[ Parent | on HN ]

Re:Go 1.8 Release Notes by ovao on Thursday February 16, 2017 @10:19PM (#13665674)

It depends on the problem domain, but it's been my experience across a few domains that many errors are of the "trivial" type you've described, in that recovering from an error by taking some alternative path is usually not very valuable. A bail-out-on-any-error approach doesn't necessarily mean it's a "toy program".

Nothing in Rust (or Go, even) ordinarily precludes the type of retry approach you're describing, of course.

[ Parent | on HN ]

Re:Go 1.8 Release Notes by ngrilly on Friday February 17, 2017 @04:01AM (#13666917)

> I know Go's team doesn't want to go in that direction.

I disagree:

https://github.com/golang/proposal/blob/master/design/15292-...

[ Parent | on HN ]

Re:Go 1.8 Release Notes by piaste on Friday February 17, 2017 @06:17AM (#13667449)

Did you check the discussion thread for that proposal? It was rejected by the mailing list devs:

https://github.com/golang/go/issues/15292#issuecomment-22198...

[ Parent | on HN ]

Re:Go 1.8 Release Notes by ngrilly on Friday February 17, 2017 @08:43AM (#13668178)

Yes, I read it.

Here is the comment you linked:

> Ian's proposal demands too much. We cannot possibly develop all the features at-once, it will exist in an unfinished state for many months.

> In the meantime, the unfinished project cannot be called official Go language until done because that will risk fragmenting the ecosystem.

> So the question is how to plan this.

> Also a huge part of the project would be developing the reference corpus. developing the actual generic collections, algorithms and other things in such a way we all agree on that they are idiomatic, while using the new go 2.0 features

The author of this comment is not a member of the core team, as far as I know, and the comment doesn't suggest the proposal was rejected.

[ Parent | on HN ]