4 ms·

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

by curun1r 10y ago

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.

iand 10y ago
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.
- ovao 10y ago
  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.
ngrilly 10y ago
> I know Go's team doesn't want to go in that direction. I disagree: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...
- piaste 10y ago
  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-221986459 https://github.com/golang/go/issues/15292#issuecomment-22198...
  - ngrilly 10y ago
    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.

by curun1r 10y ago

iand 10y ago

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.

ovao 10y ago
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.

ngrilly 10y ago

> I know Go's team doesn't want to go in that direction. I disagree: https://github.com/golang/proposal/blob/master/design/15292-generics.md https://github.com/golang/proposal/blob/master/design/15292-...

piaste 10y ago
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-221986459 https://github.com/golang/go/issues/15292#issuecomment-22198...
- ngrilly 10y ago
  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.