Go Statement Considered Harmful (2018)
Dijkstra&#x27;s paper is hard to read. I&#x27;ve gone through it and broken it down. It turns out, the central argument put forth in Dijkstra&#x27;s paper is that the &#x27;goto&#x27; statement messes up the stack trace. Although I don&#x27;t think the term &quot;stack trace&quot; existed yet, so he keeps talking about &quot;textual indices.&quot;<p>The &#x27;go&#x27; statement actually allows the cleanest stack traces of any language I&#x27;ve encountered. Go crash dumps can print 40 stack traces for 40 threads and still be shorter, cleaner, easier to read than the stack traces of something like a single line of C# async&#x2F;await code.<p>The article seems to argue that it&#x27;s hard to run more code after the completion of a goroutine. But, the entire point is you don&#x27;t have to. Go does async i&#x2F;o under the hood, so you just write the lines of code sequentially in the order you want them to happen, and they will happen at the right time.<p>As a side note about the &#x27;goto&#x27; statement, modern languages, if they have the statement at all, explicitly lock &#x27;goto&#x27; usage into one stack frame anyway. I&#x27;m 100% unconvinced there&#x27;s anything wrong with it in those instances. Anything bad things you can do with it can be done wrong as easily with other control flow.