Earlier quoted context omitted.
Even as a huge async/await fan, this is a great explanation of the problem: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... VMs that offer lightweight, blocking, non-shared memory, threads provide a great developer experience. The Dart team was experimenting with this with the Fletch VM.
While it gives good insight to the problem of sync vs async functions, I've come to find its conclusions problematic (and it rather blatantly ignores Chesterton's fence), especially with "Java did it right, but they have started to do it badly now", and especially "Go has eliminated the distinction between synchronous and asynchronous code". Ouch. You are going to think that - until your hit first deadlock or race co…
I love Go, it's my language of choice. There's a clear difference between calling a function sync or async. It's nice that we can choose to do either at will.
Oh, except that if it's an async call we have to use channels to communicate with it. Which is cool, but it's a different mechanism than if it's a sync call.
It's exactly the same as the red/blue rant about JS. If it's async you have to hand it a channel to talk to you on. If it's sync you can just wait for it to return. Async/Await same same but different.
Yes, the language does some nice stuff under the covers about pausing goroutines, but it only does that if you have multiple goroutines. If you code everything without using goroutines (and channels) then it's not concurrent and won't do the nice stuff. It'll pause for i/o just like any other language.