> Not only did I never advocate for broad usage, I explicitly said I didn't

It's not about "broad usage". You said it should be "available" and it isn't in any practical sense.

> removing it does not produce the major savings you imagine (relative to discouraging/making rare).

For setjmp/longjmp C++ already took the major savings you're thinking they won't get. Hence the Undefined Behaviour. If they wanted to not have undefined behaviour for go-to they would need to substantially re-engineer the language and that would have terrible performance. So that's not what they did.

The C++ goto keyword is completely de-fanged. Suppose you've got a loop in a scope with a complicated, expensive to destroy object. A 1960s go-to person would anticipate that if they use goto to leave the loop they are thereby skipping the expensive destruction - however in C++ it doesn't do that, the compiler performs the expensive operation to clean up properly because you are leaving scope.

> All I did was say history supported his side point and you started jumping all over me.

History does not support this claim for go-to as I've explained. You cannot actually use the go-to feature in modern languages, some offer a de-fanged goto keyword that does some local structured control flow change instead, many don't provide this at all. No that Python hack is just a hack, it's not actually implementing go-to in a meaningful sense, which is why their last example hits a recursion limit instead of just looping forever as go-to would.

> Just use a higher-level API?

The article's point is that this delivers much poorer results. I actually began trying to write an example showing how hard it would be to write structured control flow as a library in FLOW-MATIC and it hurt too much as I realised function calls don't exist and I need to begin again with that perspective, FLOW-MATIC has this idea of executing a range of instructions, but the instructions don't specify that range, the "caller" does, which today seems utterly backwards. I can't do it. Nobody would do it. At scale the resulting large programs would be - as the article observes - spaghetti code. Instead new languages were developed with structured control flow.

You've mentioned that you don't "advocate" Rust but I'll further assume you don't use it or maybe don't know it well. Historically Rust provided a mechanism that let you say well, see this object X exists now, and I just made a thread, I got a thread handle, and when I leave scope that thread handle gets joined, so, logically the thread can't exist longer than object X right? And thus it's safe to use X from inside the thread knowing it exists. That is inherently unsound and was abolished before Rust 1.0 (if you're not a Rust programmer the simple explanation is Rust has no problem with you just leaking the thread handle and then it won't get joined so the thread may outlive X)

Language-level structured concurrency would let you provide this sort of guarantee and take advantage of it in your programs. Rust is getting a very small taste of this, in the form of scoped threads in 1.53 as mentioned elsewhere in the HN threads, but the article's position, and I think it's made very well, is that doing this everywhere at the language level is desirable.

That is, rather than "just don't call it" the argument is "just don't provide it" as we saw with go-to. Are they correct? I think they might be. But it was frustrating to see several people in this thread insist that actually go-to isn't gone, citing things like longjmp which are far less powerful and explicitly have Undefined Behaviour in the circumstances discussed anyway.