Coroutine become more and more popular. Should you learn coroutine?
First, what’s coroutine? It sound new for those coders working on multithread or callback for long term. But it isn’t new stuff, really 👐 . It’s just a re-brand of callback. Yes, coroutine is just callback indeed. But it’s not new at all why we just use callback instead? Why people just waste time on it. No, no, no, it’s new stuff, actually. Just listen to me next.
What’s coroutine can do that callback can’t? Although it’s implement base on callback (or multithread, multithread-base coroutine is another implement that use stack switch but work almost like callback, I will tear it down in the future), but people extend its ability in many dims. It can do more that callback so that it’s not new stuff but new stuff. The main problem is that callback hell! What’s the hell!
This problem I believe Ajax-like-programming coder is much familiar (JavaScript can never live without callback☝️, because it is single-thread until JS worker appeared).
“Ho, wait! I didn’t meet this problem before although I’m using Ajax. I can write like that. It’s your trap. 😡”
Oh, my friend, you should read my last article and review your codes. If you write codes like that, you will get hard to collaborate with your colleagues. It’s the reason why people use callback even get trapped by the callback hell. But coroutine do magic for you.
“OK, it solve this problem. But it’s not enough to move me. 🥱”
So, let’s take a look at what people extend it that must move you. What if there may be some error nested inside those callback? But you don’t care about where will they appear(maybe they just will throw the same error). Wrap they inside a try-catch block? Not work. Because you just pass a function to async framework and the function will run in other place. Not in your block.
But with coroutine syntax, the situation is not the same. Complier or Interpreter will help you wrap your codes. Now you don’t need to do some dirty work that catch your errors everywhere. Not bad.
“Ho, wait! I can do that in multithread. It’s your trap, too. 🤬”
Oh, my friend, when you project become large, create threads many time will hurt your performance and also lose some performance on wait “other thread”, not worth to do that. 😨 (Yeah, you can use threadpool. But when you do that, your software is just a coroutine-like program with some thread lock dirty work but without coroutine-syntax. Not worth to re-create that others already done. )
Another benefit is that async generator. Think about sequential data come from some place but now they are async. Oh no, I need to handle these data before other sync or async codes. If you directly append later codes after generator and it doesn’t work that later codes will run immediately. Now you know you get trap by the hell again.
Don’t worry, coroutine help you.
Now your code is sequential, easy to understand and also high efficient at the same time.
Now, should you learn coroutine? No, just treat it as a new syntax of callback-style programming is enough. There really is nothing you need to learn that you already known. Why you should learn coroutine? But please use it in the next time.
