I'm genuinely hoping that after generics, the focus will be on error handling from the survey results Go devs in a lot of communities love to put their heads in the sand going "error handling is perfectly fine". But it's not fine. Not even close. And I'm very happy there's a lot of demand for some solution in this space. It's just plain too verbose without any of the actual benefits of that verbosity. You don't have…
I would love to see some in-depth discussion about this. Even in 2022, I don't think it's clear what we want error handling to look like. You can ask for correctness guarantees from the compiler, but it's easy to ask, it's harder to design a system that actually works. > The lack of exhaustive switch case statements makes this worse because the compiler doesn't care if you're handling all the expected error types (or…
myFunc() works as today
myFunc()^ returns the err if there is one
myFunc()! panics if there is an err