Definitely do.
In Go we just have to emulate it, badly, by manually writing code to forward the error up the stack so you can finally top-level print “error bad thing happen” or maybe some unholy stringification of wrapped errors possibly collected along the way.
But the correct and only sane way to do this is Either<Error, Success> that you can then pass on, map over both or either of the two, flatMap to chain with other EIthers, fold into a single thing etc etc. (and no, these are not obscure, esoteric or difficult operations - they're the same for other types like Option, List etc and are trivial to learn in a day for people who aren't familiar with them) Not endless sprinkling of
if err != nil { log.Fatal(err) }
everywhere
+ not making the compiler distinguish between null and non-nully values (as eg Kotlin, Rust and Haskell does) in itself as well is inexcusable for a modern language
Also, did you come up with this on your own, or were you exposed to it?
+ other languages get close, eg Kotlin has nullable types (which is a poor substitute) and Result (which is also poor because it's not a true Either)
that said lots of languages these days have libraries that do it (Arrow, Vavr and countless others)
IMO the killer simple language that Go tries and fails to be would be something like a Kotlin+Arrow with heavily reduced syntax and features, eg
no exceptions (use Either or a correct Result type)
no loops (use map, fold etc)
no nulls (use a correct Option/Maybe type)
etc etc
= in such a language, we learn that methods return things, those things will be what they say they are (guaranteed by the compiler), they will tell you what you can do with them, and if a program compiles, you can be pretty damn sure it works as intended
insert "all the languages are broken, I should create a new language" meme here...
> in itself as well is inexcusable for a modern language
In Go, you can assign nils only to pointers
func myfunc(url string) Result[string] {
tup := FromTuplePtr(http.Get(url))
return FlatMap(tup, func(r http.Response) Result[string] {
return Map(FromTuple(io.ReadAll(r.Body)), func(b []byte) string {
return string(b)
})
})
}
Golang _has_ sane error handling. It just considers errors a normal and expected situation.
When you perform a http request, and the result is successful you expect the result to be assigned a variable, right? Then why would you expect non-successful outcome to be returned in a different way? Why is it different? Why do you unwind the stack? Something terrible happened? Definitely not, it's as real life as 200 OK.
For unrecoverable things golang has panics, and if you don't like the idiomatic way of handling errors, you can just throw them like exceptions.