My takeaway is that Go almost always prefers simplicity and not so much good software engineering. `nil` without compiler checks is another example, or designing a new language without generics. However the overall simplicity has its own value.
Why Go Can't Try
71–74 of 74 posts
Re: Why Go Can't Try
#72Re: Why Go Can't Try
#73Earlier quoted context omitted.
> if the return type is `Result `, the caller cannot access the `MyDataType` without using some code that acknowledges there might be an error (match, if let, unwrap etc.) I think you can make the same argument here - rust provides unwrap and if you don’t know go, that’s just how you get the value out of the Result Type.
The big difference is that with `(T, error)` as a return type, any value on the caller side will look like a valid one (thanks to zero values). a, err := f() // whether you forgot to handle the `err` or not, // the `a` carries a zero value, or some other value. In rust it's not the case, as the `T` in `Result ` won't be constructed in case of an error.
Or you could return pointers and use `nil` in the error case. Bonus is that it'll then panic if you try to use it without checking the error.
(Yes, I know, it makes everything else a faff and is a silly idea.)
Re: Why Go Can't Try
#74Earlier quoted context omitted.
Go specifically does not want to add QoL things because it means the compiler team has to spend time implementing that extra syntax and semantics versus making a minimal set of features better.
The problem with the zero value business is that it also makes adding these QoL things in libraries difficult or outright impossible. Case in point, I tried building a library for refinement types, so you can have a newtype like, type AccountName string except you write it like (abridged) type AccountName refined.Scalar[AccountName, string] func (AccountName) IsValid(value string) bool { return accountNameRegexp.Matc…
You can use pointers and then `encoding/json` will leave them as `nil` if the field is missing when you `Unmarshal`. I believe the AWS Go SDK uses this technique for "optional" fields (both input and output.) Obviously more of a faff than if it supported truly "unset" fields but it is what it is.