Sure they are. The abstraction they provide is a synchronous API, but it's accomplished using an async runtime.
Async is really about the surface syntax and ergonomics, not the implementation.
Goroutines are an unusual case, in that they don't have cooperative concurrency--they're pre-emptive--but the Go runtime does perform I/O using concurrent multiplexers under the hood.
So goroutines are kind of both: computation execution and code semantics look like pthreads, but I/O operations look like NodeJS on the backend.
Now, I'm not sure what "async runtime" means in the GP. If they're referring to I/O multiplexers, then they should say that. If they're referring to something else, then I'm not familiar with other uses of that term that would accurately apply to Golang.
Async and threads are a lot closer than most people think. An OS is mainly a queue for swapping between async operations, and a collection of abstracted services that the async operations can request, like network or disk i/o.
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
Like, do you need async runtimes to do epoll async in Rust? No. Ok, so that excludes many definitions. Do you need coroutines in C++ to do aio for reading and writing? No.
So like I said, what do they mean by "async"? The blog post refers to a web server that does "async" in Rust without any async runtime, and without the `async` keyword.
In other words, that parent commenter is what's called "not even wrong".
