Kotlin coroutines implementation looks like CPS(stackless) state machine generator with api for continuation scheduling factory. Looking at “Guide to kotlinx.coroutines by example” this makes it really powerful implementation in some ways superior to JS and C# async/await analogs.[/quote]
I guess you are referring to CSP which means communicating sequential processes. As you don’t seem to know much about it I can recommend to read the book about it by the creator of CSP, Toni Hoare, which you can get from here as a PDF.
No, Go which is fully based on CSP is a big success. It is currently on Tiobe at position 14. There are many Go developers nowadays. Apparently they picked up CSP very quickly and really like it.
No, reading concurrent code based on channels is a lot easier than trying to follow asynchronous calls. It is also a lot easier to find the reason for a race condition or deadlock and to fix the issue than with asynchronous programming. The is the very point of CSP. Robert Pike is saying in Origins of Go Concurrency (from about position 29:00):
“The thing that is hard to understand until you’ve tried it is that the whole business about finding deadlocks and things like this doesn’t come up very much. If you use mutexes and locks and shared memory it comes up about all the time. And that’s because it is just too low level. If you program like this (using channels) deadlocks don’t happen very much. And if they do it is very clear why, because you have got this high-level state of your program ‘expressing this guy is trying to send here and he can’t, because he is here’. It is very very clear as opposed to being down on the mutex and shared memory level where you don’t know who owns what and why. So I’m not saying it is not a problem, but it is not harder than any other class of bugs you would have.”
In Go you cannot look at a goroutine in the debugger at all. Goroutines are completely locked away from the user. This is on purpose, because it is supposed to be transparent and the user is prevented this way from creating a mess. The success of Go and the enthusiasm of Go developers shows that the point you are mentioning is not an issue. Not every debugger can handle some ten thousand or hundred thousand green threads (aka coroutines or goroutines). This is something you could have brought forward. But you didn’t due to lack of understanding.
I suggest that YOU investigate other popular communities and investigate CSP a bit more carefully. This way many of your harsh and inappropriate comments could have been avoided. CSP is so easy to study by looking at Go where things are very well explained and documented. But apparently you didn’t have a look into all the material provided there.