I think it's fine to add syntactic sugar for panic. The standard library already has similar functionality, like regexp.MustCompile. And personally, I've implemented a Must function in many services. E.g. you try to parse a config file during service startup and parsing fails. There is no recourse from such an error. I'm sure I'm not the only one who has implemented such functionality, so why not add it to the language?
Regarding the guard keyword, the author's proposal doesn't make sense. The guard call comes after the function call that produces the error, so it's not clear what is being guarded. I guess it's the error being wrapped in the guard message, but explaining that clearly in plain English is quite hard. I agree that context is important however. But maybe the Go team is finally ready to admit that stack traces are more useful than error messages. I'd be fine to know that, for example, an error occurred opening a file and having the language provide a full stack trace of where the error happened. I can do without the custom crafted error messages.
Regarding the guard keyword, the author's proposal doesn't make sense. The guard call comes after the function call that produces the error, so it's not clear what is being guarded. I guess it's the error being wrapped in the guard message, but explaining that clearly in plain English is quite hard. I agree that context is important however. But maybe the Go team is finally ready to admit that stack traces are more useful than error messages. I'd be fine to know that, for example, an error occurred opening a file and having the language provide a full stack trace of where the error happened. I can do without the custom crafted error messages.