Hacker News Reader

Go can’t have Result because they don’t have sum types, and they can’t add them because of their bizarre insistence that every type has to have a designated zero value.

> they can’t add them because of their bizarre insistence that every type has to have a designated zero value.

Nothing prevents adding union types with a zero value. Sure it sucks, but so do universal zero values in pretty much every other situation so that's not really a change.

Making it so all sum types have to be nillable would make them dramatically worse (the basic motivating example for sum types is Option, the whole point of which is to get rid of NULL). I guess this is in agreement with your point.

> the basic motivating example for sum types is Option, the whole point of which is to get rid of NULL

I don't think that's the case in Go: whereas I got the impression the C# team started souring on default() after generics landed (possibly because nullable value types landed alongside and they found out that worked just fine and there was no reason nullable reference types wouldn't) I don't really get that impression from the Go team, even less so from them still mostly being Googlers (proto3 removed both required fields and explicit default values).

In Scala basically all types are nullable (including Option/Try/Either), but it never really comes up because no one uses nulls (except when wrapping java code) because the language makes it easier to just do the right thing almost all of the time.

In fact the lack of sum types seems to be why you need everything to have a zero value in the first place: because sums are products you need a nonsensical value when the sum is the other type.

I've read elsewhere that one idea for the zero value of sum types is not making it nillable, but rather making the zero value as the 0th variant of the sum type (and if it has associated data, the zero value of that as well).

It's weird, but does align with design decisions that have already been made.

So if there was an `Option[T]` with variants `None` and `Some[T]`, the zero value would be `None` because that's the zero-th variant

> every type has to have a designated zero value

This bonkers design decision is, as far as I can tell, the underlying infectious cause of nearly every real issue with the language.

> But I fail to see how having convenience equates to ignoring the error.

The convenience of writing `?` means nobody will bother wrapping errors anymore. Is what I understand of this extremely dubious argument.

Since you could just design your `?` to encourage wrapping instead.

> Since you could just design your `?` to encourage wrapping instead.

Which is exactly what Rust does -- if the error returned by the function does not match the error type of `?` expression, but the error can be converted using the `From` trait, then the conversion is automatically performed. You can write out the conversion implementation manually, or derive it with a crate like thiserror:

    #[derive(Error)]
    enum MyError {
        #[error("Failed to read file")
        IoError(#[from] std::io::Error)
        // ...
    }

    fn foo() -> Result<(), MyError> {
        let data = std::fs::read("/some/file")?;
        // ...
    }

You can also use helper methods on Result (like `map_err`) for inserting explicit conversions between error types:

    fn foo() -> Result<(), MyError> {
        let data = std::fs::read("/some/file").map_err(MyError::IoError)?;
        // ...
    }

1. That is a global static relationship rather than a local one dynamic one, which is the sense in which Go users use wrapping.

2. Idiomatic go type erases errors, so you're converting from `error` to `error`, hence type-directed conversions are not even remotely an option.

> That is a global static relationship rather than a local one dynamic one, which is the sense in which Go users use wrapping.

In practice, the error type will be defined quite close to where the conversion is applied, so the static nature of it doesn’t feel too big.

`map_err` does not need to be type-directed; you can use an arbitrary function or closure. An enum variant can be used as a function mapping from the variant type to the error type, but we can do any arbitrary transformation:

    .map_err(|e| format!("Failed to read file: {e}")?;

But the "idiomatic Go" way of doing things sounds a lot closer to anyhow in Rust, which provides convenience utilities for dealing with type-erased errors:

    use anyhow::{Result, Context};

    fn foo() -> Result<()> {
        let data = std::fs::read("/some/file").context("Failed to read file")?;
        // ...
    }

Yes, I know that, but the argument (which, again, I called dubious) is that in both cases it's much easier to do just e.g.

  fn foo() -> Result<()> {
      let data = std::fs::read("/some/file")?;
      // ...
  }

whereas the current morass of Go's error handling means adding wrapping is not much more of a hassle.

But of course even if you accept that assertion you can just design your version of `?` such that wrapping is easier / not wrapping is harder (as it's still something you want) e.g. make it `?"value"` and `?nil` instead of `?`, or something.

You need to implement from for every type of error then? That seems pretty tedious also.

> The convenience of writing `?` means nobody will bother wrapping errors anymore.

A thread from two days ago bemoans this point:

https://news.ycombinator.com/item?id=44149809

> I dont see why the Rust style isnt just adopted.

Mostly because it is not entirely clear what the Rust-style equivalent in Go might be. What would Rust's "From" look like, for example?

Sorry, I wasnt specific in that part. When I say 'rust style' Im really just referring to a union type of `result | error`, with a way to check the state (eg isError and isResult) along with a way to get the state (eg getResult and getError). Optionally '?' and '!' as sugar.

That said, the other responder points out why the sum type approach is not favored (which is news to me, since like I said I havent followed the discussion)

In Go, values are to be always useful, so `result | error` would be logically incorrect. `(result, result | error)`, perhaps – assuming Go had sum types, but that's a bit strange to pass the result twice.

Just more of the pitfalls of it not being clear how Rust-style applies to an entirely different language with an entirely different view of the world.

What is useful about the value of `x` in the following code?

  x, err := strconv.Atoi("this is invalid")

On the contrary, `x` is _lying_ to you about being useful and you have absolutely no idea if the string was "0" or "not zero"

> and you have absolutely no idea if the string was "0" or "not zero"

You do – err will tell you. But in practice, how often do you really care?

As Go prescribes "Make the zero value useful" your code will be written in such a way that "0" is what you'll end up using downstream anyway, so most of the time it makes no difference. When it does, err is there to use.

That might not make sense in other languages, but you must remember that they are other languages that see the world differently. Languages are about more than syntax – they encompass a whole way of thinking about programs.

I think it's worth noting that, while the general consensus has converged around (T, error) meaning T XOR error, it does not necessarily mean that. There are some places that violate this assumption, like the io.Reader and io.Writer interfaces. Especially io.Reader, where you can have (n>0, io.EOF), which also isn't even a proper error condition! (This isn't a big problem, though, since you rarely need to directly call Read or Write).

If a function `func foo() (int, error)` returns a non-nil error, then the corresponding `int` is absolutely invalid and should never be evaluated by the caller, unless docs explicitly say otherwise.

And this is why I prefer exceptions.

Errors are common but they are errors: they absolutely represent an exceptional branch of your control flow every time.

It seems reasonable to ask if that int should even be available in the control flow syntactically.

Errors are just values, same as other values, it's in no way "exceptional" for a caller to get an error back from a call to some other code. If a function can fail it needs to return an error, if a function call fails the caller needs to deal with that error, not difficult stuff here. "Happy path" is no more or less important than "sad path" and both should be equally represented in the source code as written.

That's doctrine. Saying it doesn't make it useful.

A program serves a business need: so it's well recognized that there's a distinction between business logic, and then implementation details.

So there's obviously no such thing as "just an error" from that alone: because "a thing failed because we ran out of disk space" is very different to "X is not valid because pre-1984 dated titles are not covered under post-2005 entitlement law".

All elephants have 4 legs, but not all things with 4 legs are elephants, and a tiger inside the elephant enclosure isn't "just" another animal.

You're simply wrong. If I call a function and it fails, then at the base level it doesn't matter if it failed because "no more disk space" or because "input values are invalid" -- the thing failed, in both cases. The caller needs to deal with that failure, in all cases. Now exactly how it deals with that failure might depend on properties of the error, sure, but the control flow of the program is the same in any case.

> So there's obviously no such thing as "just an error" from that alone

The point is that all values are potentially errors. An age value, for example, can be an error if your business case requires restricting access to someone under the age of 18. There is nothing special about a certain value just because it has a type named "error", though.

Let's face it: At the root of this discussion is the simple fact that "if" statements are just not very good. They're not good for handling errors, but they're also not good for handling anything else either. It is just more obvious in the case of what we call errors because of frequency.

Something better is sorely lacking, but seeking better only for types named "error" misses the forest for the trees.

To be fair Rust doesn't have sum type it has enums, which I feel like you could do in Go, but I haven't read the arguments.

Technically, Rust has sum types (a.k.a. tagged unions) that use an enum to generate the tag. So, while enumeration is involved, sum types is still a better description of what it is.

Enum is what they call it (perhaps to appear more familiar to C++ programmers?), but from a computer science standpoint they are classic sum types.

It's an interesting idea. Right now, you can do something like this:

    res := someFunc() // func() any
    switch v := res.(type) {
    case error:
        // handle error
    case T:
        // handle result
    default:
        panic("unexpected type!")
    }

Then, presumably, a T|error sum type would be a specialization of the any type that would allow you to safely eliminate the default arm of the switch statement (or so I would like to think -- but the zero value issue rears its ugly head here too). Personally, I'd also like to see a refinement of type switches, to allow different variable names for each arm, resulting in something like the following hypothetical syntax:

    switch someFunc().(type) {
    case err := error:
        // handle error
    case res := T:
        // handle result
    }

However, there's no real syntactic benefit for error handling to be found here. I like it (I want discriminated unions too), but it's really tangential to the problem. I'd honestly prefer it more for other purposes than errors.

> What would Rust's "From" look like, for example?

Idiomatic Go type-erases error types into `error`, when there is even a known type in the first place.

Thus `From` is not a consideration, because the only `From` you need is

    impl<'a, E> From<E> for Box<dyn Error + 'a>
    where
        E: Error + 'a,

and that means you can just build that in and nothing else (and it's really already built-in by the implicit upcasting of values into interfaces).

> Go type-erases error types

That's clearly not true.

    type MyError struct{}
    func (MyError) Error() string { return "MyError" }

    func main() {
        var err error = MyError{}
        fmt.Printf("%T\n", err) // Output: main.MyError
    }

The idea doesn't even make any sense. How could you even begin to handle errors in a meaningful way if you were unable to discern what type the error is?

- It has poor visibility, it hides control flow branches in a single statement / expression. That's one of the reasons Go got rid of the ternary operator in favor of an if statement where each branch has to be on its own line.

- It isn't easily breakpointable.

- It favors "bubbling up" as-is over enriching or handling.

Wait...

  x, err := strconv.Atoi("123")
  if err != nil {
    panic(err)
  }
  y, err := strconv.Atoi("1234")
  fmt.Println("result:", x, y)

> this also compiles and runs just fine but again you would have no idea something was wrong

Okay, I don't use golang... but I thought ":=" was "single statement declare-and-assign".

Is it not redeclaring "err" in your example on line 5, and therefore the new "err" variable (that would shadow the old err variable) should be considered unused and fail with 'declared and not used: err'

Or does := just do vanilla assignment if the variable already exists?

As I understand it, go has some special handling for this scenario because its so prevalent which special cases reassignment. The linked article touches on it

> There are exceptions to this rule in areas with high “foot traffic”: assignments come to mind. Ironically, the ability to redeclare a variable in short variable declarations (:=) was introduced to address a problem that arose because of error handling: without redeclarations, sequences of error checks require a differently named err variable for each check (or additional separate variable declarations)

... I thought Go's whole deal was that you give up the expressiveness and power of overdesigned languages for simple, clean, "only one way to do it" semantics. That "special cases reassignment" where ':=' is sometimes a shadowing declaration and sometimes a reassignment sounds like the opposite of that.

The language is full of gotchas like that, you're expected to use the tooling to guardrail yourself, because having a proper type system or coherent syntax is "too complicated" (while learning dozens of patterns and weird tricks apparently isn't).

go vet and this massive collection of linters bundled into a single binary are very popular: https://golangci-lint.run

linters will warn you of accidental shadowing, among many other things.

> That "special cases reassignment" where ':=' is sometimes a shadowing declaration and sometimes a reassignment sounds like the opposite of that.

FWIW it is never a shadowing declaration. It is at least one non-shadowing declaration plus any number of reassignments.

The fun part is the tendency to keep reassigning to `err` makes the unused variable largely useless, so it’s just there to be a pain in the ass, and your need a separate lint anyway.

It's trickier than that, unfortunately. There has to be at least one new variable on the left side of := but any other variables that already exist in the same scope will simply be assigned to. However, if you use := in a nested block, then the variable is redeclared and shadows the outer-scope variable.

Thanks, I hate it.

This, along with stuff like implicit access modifiers based on case, nil interface confusion, named or multiple return values, channel lockups, and `append` oddities make it ring a bit hollow when people complain that no-one could be expected to google once and learn what snippet a `?` operator expands to. Like I don't even necessarily hate all these things, just please don't pretend it's the heart and soul of minimalism or approachable predictability.

Yeah, people complain about `if err != nil`, but the real issues are tricky rules around variable shadowing, lack of nil safety and immutability, cgo, defer semantics, etc

Oh no, you are making the classic mistake of assuming Go’s designers did something that would make sense, rather than picking the most insane possible design in a given situation.

> Its the thing I immediately add now that I have generics in Go.

If you’re willing to share, I’m very curious to see a code example of what you mean by this.

This is from a while back but was the first thing I thought of: https://gist.github.com/J-Swift/96cde097cc324de1f8e899ba30a1...

I ripped most of it off of someone else, link in the gist

Moving every success value to the heap seems like a big loss to me but I don't see an alternative. I think going the interface route also ends up wrapping everything in an even fatter pointer. But at least I get to think "ah maybe this isn't going to get boxed and it will be free".

    interface Result[T] {
     IsOk(): bool
     IsErr(): bool
     Unwrap(): T
     UnwrapError(): error
    }
    
    // Ok is a Result that represents a successful operation.
    struct Ok[T] {
     Value: T
    }
    
    func Ok[T](value T) Result[T] {
     return Ok[T]{Value: value}
    }
    
    func (s Ok[T]) IsOk() bool {
     return true
    }
    
    func (s Ok[T]) IsErr() bool {
     return false
    }
    
    func (s Ok[T]) Unwrap() T {
     return s.Value
    }
    
    func (s Ok[T]) UnwrapError() error {
     panic("UnwrapError called on Ok")
    }
    
    
    // Err is a Result that represents a failed operation.
    struct Err[T] {
     Reason: error
    }
    
    func Err[T](reason error) Result[T] {
     return Err[T]{Reason: reason}
    }
    
    func (e Err[T]) Error() string {
     return e.Reason.Error()
    }
    
    func (e Err[T]) IsOk() bool {
     return false
    }
    
    func (e Err[T]) IsErr() bool {
     return true
    }
    
    func (e Err[T]) Unwrap() T {
     panic(fmt.Errorf("Unwrap called on Err: %w", e.Reason))
    }
    
    func (e Err[T]) UnwrapError() error {
     return e.Reason
    }