>On the one hand, we have the "clearly superior" Rust approach to error handling that checks a lot more at compile time than Go does, but on the other hand, Go programmers don't ever need to "learn error handling" at all. They have a simple convention with a reasonably low bug rate (IME, anyway).

I don't think you misjudges the differences in complexity here at all. But wouldn't that have more to do with the different approaches to memory management?

>aforementioned cognitive load without giving up those sweet sweet compile time checks

I would argue the cognitive load comes mostly from nominal typing and lack of type inference. A counter example would be the Crystal language which has a very strong type system, but is exposing barely any of it as 'added cognitive load'.

This correlation between 'cognitive load' and 'expressiveness of a typesystem' seems unfair. Having to keep track of all the patterns that are valid but not supported by the type system is also a type of added (hidden) complexity.

Even the poster-feature of Rust has a (IMO) much easier cousin with the same (and more) advantages called 'the Clean programming language' in the shape of 'uniqueness types'. And most of the complexity in Rust is the result of the type system not being expressive enough for how they are attempting to use it, rather than the opposite.