You are entirely correct. My sentence "The main difference between async calls and threads is that threads remove the distinction between synchronous and asynch

You are entirely correct. My sentence "The main difference between async calls and threads is that threads remove the distinction between synchronous and asynchronous code." is pretty weird: I wasn't talking about threads in general, but green threads as used by Go (i.e. Goroutines) in particular. The idea that I wanted to express is that, very broadly, there are two ways of dealing with concurrent io. One is to deal with it explicitly at call site, using some variation of async/await semantic, futures, promises, or just callbacks. That's the C#/Python 3.4+/javascript way of doing it. Although implementations vary wildly between these languages, the core idea remains the same. The other way of dealing with concurrent io is using green threads (or related concepts like actors) as in Go, Elixir, Python with gevent, etc. IO calls don't look special (no await, no yield, no special keyword, no callback), that is to say they behave like any other function call (although the implementation of these io calls is non-blocking to allow other green threads to run). Concurrent io from the programmer perspective is achieved simply by spawning many green threads/actors. I personally find green threads easier to reason about than async calls, especially in the long run when maintaining large software.