Hacker News Reader

Comment by OJFord | Hacker News Reader

I've learned to consider it an excellent feature, but is Go's implementation/idiom really better than anything that came before it?

I have marginally more experience with Rust (not that much of either) which instead gives Result types, tuples of 'ok' and error values. And, crucially for this thread, they must be explicitly consumed.

That enforced error handling is novel to Rust afaik, and after a bit of getting used to, an excellent feature I think.

But I'm not sure that the idiomatic (because that's all it is really, rather than language feature?) Go is materially different from deciding all your Python functions will return Tuple[TOk, TErr] and sticking to it, or even that different from returning ok types only and raising exceptions, really.

View on HN

> That enforced error handling is novel to Rust afaik

Hardly, though Rust of course has merit in making it popular, to the point that people think it was introduced by the language.

Well that's why I said as far as I know. What else has something similar?

Haskell's Maybe type (monad?) comes to mind.

That's true, it's a while since I did only a little bit of Haskell, but yes. I suppose I didn't think of it because it feels less like 'having to handle' it in Haskell, since that's the norm anyway.

Whereas if you compare Rust to Python, C(++), or Go as I was - having to consume a returned 'result' is more notable.

Anything with ADTs. I know it from the ML family of languages (Ocaml, Standard ML, F#, etc.)

> Anything with ADTs.

Well that's not true, that's completely orthogonal?

It's not. "Forced error handling" in Rust (particularly when contrasted with something like Go like we're doing here) is exemplified with the Option and Result types, and how the compiler will maintain type safety around the concepts of success and error. ADTs are what lets it do that, and the MLs do that as well. You can also see this in how Typescript for example uses ADTs for typesafe error/success state space enumeration.

But you could have ADTs without using them for 'forced error handling', and you could have 'forced error handling' without using ADTs for it - C could require 'consumption' (for a slightly less strict meaning of it) of return values. That's the bit I think is interesting/was new to me. You can't just call `maybe_works();`, you have to explicitly consume its 'result', even if just to propagate the error as `maybe_works()?;`.

Oh, ok. Yeah that in fact does exist in C and C++ the same way as in Rust. Rust doesn't actually by default require you to consume a return value; a lot of functions are just marked as #[must_use]. C and C++ do the same thing with [[nodiscard]] and __attribute__((warn_unused_result)).

There's a go vet pass as well. https://pkg.go.dev/github.com/golangci/govet#hdr-Unused_resu...

No, not really, it's an accurate summation of where the pattern is commonly found. ADTs, like Rust's Enum, enable this kind of error handling, and are made more ergonomic with monad behaviors.

Scala's Either[A, B] is another example.

Yes, but Haskells'/Scalas' Either is abstract while Rusts' Result is specific SFBAP (Sorry For Being A Pedant).

Can you clarify the distinction between "abstract" and "specific"?

Is Scala's Try[A] "specific"?

Sure. Result is specific, you get a value or an error. Either can be used the same way, but you don't have to. The convention is use Right for the value and Left for the error but you can use it in other ways too, eg Left for an Int and Right for a Float.

I think one difference between Rust and OCaml is that in Rust non exhaustive pattern matches are an error, while in OCaml they are a warning.

Reply on news.ycombinator.com