Hacker News new | past | comments | ask | show | jobs | submit login

> and I’m being generous with “emerging” here, the Either monad is more than an emerging consensus around the right default for error handling

It is clearly the right way, but Go's error handling already has 80% of its benefits. Switching over to a Result type at this point would require a lot of churn for little benefit.

Sum types on the other hand...

> it sucks oxygen out of the room on more plausible C successors like D and Jai and Nim and Zig and V and (it pains me to admit but it’s true) Rust.

D is dead, never even heard of Jai, Nim hasn't caught on, can't believe you're mentioning V. Rust competes mostly with C++ and is unlikely to appeal to C enthusiasts. Zig is promising, but it's in very early stages.

Go is used because it fills the glaring hole of a reasonable, modern, fast and GCd language. It reflects poorly on PL designers that we don't have a properly designed modern language in the space and have to make do with Go. Some combination of Go+Rust would be perfect, but it just does not exist.




I am doing pretty well with ML derived languages, or its influence in JVM/CLR offerings + GraalVM/OpenJ9, thankfully I only get to deal with Go on DevOps related tooling, and some of it has already been rewritten into Rust.


> It is clearly the right way

It's clearly not. Either<T, Err> creates a dependence between T and Err that should not exist. They are logically independent variables. The state of Err has no reason to imply anything about the state of T.

I'd be inclined to agree that, for all practical purposes, it is the best we've got, but that doesn't mean it is right. An ideal language can do better.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: