[neilparikh]

> but what about upsides?

I don't know much about Go, and I'm one of those people who mostly sees the downsides, so I guess I'll ask you about one of my biggest issues with the language (in the hopes of broadening my perspective on this): what is the upside of returning a value and error, rather than a value or an error? Or I guess, more precisely, why is that the default and only way to do things [1]?

For context, I'm a big fan of explicit errors and errors as values over exceptions as a general principle: my preferred language is Haskell, where Either (essentially Result) is the main way to doing error handling, and exceptions are very rarely used.

[1] - I can see a few cases where returning both is useful, but I can't see it being what I want most of the time

[philosopher1234]

I agree that Either is more semantically correct. But is it more readable? Is it easier to manipulate? I don't think so. To have either, you need two big concepts:

1. Sum types. These can be really useful, and they _might_ improve Go, but they are undeniably a new complication and something users must now understand to work with Go code. This is not free. Is it the best use of developer minds to be paying rent to the Sum type concept? Or might dev teams be better off using that rent on some other domain specific problem?

2. Unwrapping. Now you have a container for your data, and you have to peel it apart to manipulate the data. This is a minor cut, but it adds up over time, and I think it leads to necessarily more convoluted code. `if err != nil` is the cost of separate err types, but visually its minor and Goland at least auto-collapses it so it interferes as little as possible with your code. I think matching on errs, or just propagating the error case, are both more complex for readers to parse. Furthermore, propagating a naked error loses crucial context (where in this function did we fail? what info from this function do I need to debug this?) that is dead simple to add in Go.

I think a sum typed has a semantic advantage, but it also has a cost, and I think you can make an argument its not worth the dough.

[macrael]

Not to get in the way of the fun, but my point at the start was less about the semantics of an Optional type in particular, but more about how in the absence of an Optional (or I suppose a nil value) people abuse nil pointers as a stand-in, and that's been a source of lots of bugs I've seen.

The language was designed without a nil value opting instead for an empty value. It turns out that in lots of real-world applications some kind of affordance for "this doesn't exist" is so common that even standard libraries use nil pointers to model that. That leads to bugs because now lots of things are pointers that don't actually need to be passed by reference and the language's affordance for _everything_ being able to be passed by value is being circumvented. An optional type (even without any full blown support for sum types in the language) would have solved this problem neatly.