Async is to deal with io not for all concurrency in general. It uses interupts, not threads. Although the implementation can use threads for optimisation, it is not the point. If you're waiting on a network socket or reading lots of files, you don't need to spawn a new thread for each item. You can instead schedule a task to run one an interupt is received.
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.
