What's most interesting to me personally is that if you squint, Martin is essentially making an argument for a low-level parallel to Java's Thread.stop method (although in much more detail). I always thought that Java's deprecation of Thread.stop was a huge cop-out from actually solving the underlying causes of its issues, and very disappointing. But from a high-level view, there are often differences between whether a thread should be stopped when its ready, or if a thread is no longer useful and should be terminated immediately.
Its also interesting that go's solution to this is to pass a context with a 'done' channel through every function call dealing with a specific session, and every time a channel is waited on you also wait on the done channel. While its an effective method, its a bit of a shame that the concept wasn't built into go more deeply.
Some relevant articles:
- Why Thread.stop was deprecated: http://docs.oracle.com/javase/1.5.0/docs/guide/misc/threadPr...
- Go concurrency patterns: https://blog.golang.org/context