This is a pretty disingenuous criticism.
> The fact that the stdlib HTTP utils in Go recover from panics in handlers and provide no way of changing this
It's comically easy to just wrap the root handler, catch panics yourself, and explode.
> You need to provide your own error handling middleware (of which several exist).
And you need to provide your own handlers anyways, which seems reasonable to me, unless you're against writing code?
> A beginner needs to be very careful and read the docs to catch e.g. this line:
Yes you need to read the docs to understand what a function does. This does not require being very careful where I'm from.
> Also, the fact that Go kind of blesses the use of panics internally in a library ... makes for even more brittle software, as predicting what state a control flow interruption like panic through a call stack leaves your data in can be challenging and require great care to avoid invariants being violated.
They make this pretty clear, that you shouldn't leak the panic, in which case it's just an implementation detail. If your library is brittle, that's on the implementer. You don't have to use panics for control flow. It's just something you can do. A tool. Sure, maybe it's sharp.
> I don't like brittle stuff like encouraging panic-like control flow for non-exceptional situations
I've never seen anything remotely encouraging use of panic for control flow. The blog post even states it's uncommon and unusual. I don't know how you interpreted that blog post, which reads to me as "here's how defer works", to being "you should use panic for control flow whenever possible."
> The fact that the stdlib HTTP utils in Go recover from panics in handlers and provide no way of changing this
It's comically easy to just wrap the root handler, catch panics yourself, and explode.
> You need to provide your own error handling middleware (of which several exist).
And you need to provide your own handlers anyways, which seems reasonable to me, unless you're against writing code?
> A beginner needs to be very careful and read the docs to catch e.g. this line:
Yes you need to read the docs to understand what a function does. This does not require being very careful where I'm from.
> Also, the fact that Go kind of blesses the use of panics internally in a library ... makes for even more brittle software, as predicting what state a control flow interruption like panic through a call stack leaves your data in can be challenging and require great care to avoid invariants being violated.
They make this pretty clear, that you shouldn't leak the panic, in which case it's just an implementation detail. If your library is brittle, that's on the implementer. You don't have to use panics for control flow. It's just something you can do. A tool. Sure, maybe it's sharp.
> I don't like brittle stuff like encouraging panic-like control flow for non-exceptional situations
I've never seen anything remotely encouraging use of panic for control flow. The blog post even states it's uncommon and unusual. I don't know how you interpreted that blog post, which reads to me as "here's how defer works", to being "you should use panic for control flow whenever possible."