The original PR line taken by Go team was that langauges like Java "communicate by sharing" whereas in Go you would "share by communicating". It wasn't so much

The original PR line taken by Go team was that langauges like Java "communicate by sharing" whereas in Go you would "share by communicating". It wasn't so much about Green vs Native threading as it was about the core semantics of Goroutines and Channels. This original PR also had annoying (to people such as myself) aspect of poopooing Java in context of concurrency (of all things). As it happens [lol] facts asserted themselves and (at least some in) Go community saw the reason as to why "communicating by sharing" paradigm ever got traction. "It's performance, stupid", to paraphrase Slick Willy, not because other language designers were thoughtless. So now it is "idiomatic" to see Go code using both paradigms (locking & passing channels). The original matra was quietly dropped along "systems programming PL" bit somewhere along the line. This OP type of article, in an interesting way, continues this pattern of "let's do it this [obvious] way" in face of dealing with concurrency. No less an authority than Cliff Click has asserted that lock-free type algorithms pretty much require a GC. Concurrency and memory management seem to be zero-sum games. Root cause is clearly Physics, and not the mechanism devised to deal with the physical realities.