I actually like the explicit error and context value stuff in Go, though I recognise I'm in the minority.

The main reason is more to do with maintaining Go code than writing it: I find it very helpful when reading Go code and debugging it, to see actual containers of values get passed around.

Also, whenever I write a bit of boilerplate to return an error up, that is a reminder to consider the failure paths of that call.

Finally, I like the style of having a very clear control flow. I prefer to see the state getting passed in and returned back, rather than "hidden away".

I know that there are other approaches to having clear error values, like an encapsulated return value, and I like that approach as well - but there is also virtue in having simple values. And yes there are definitely footguns due to historical design choices, but the Go language server is pretty good at flagging those, and it is the stubborn commitment to maintaining the major API V1 that makes the language server actually reliable to use (my experience working with Elixir's language server has been quite different, for example).