I have no skin in this game, as I’m not a serious JavaScript developer, even on a part-time basis. However, as an early adopter of IcedCoffeeScript, since I worked with it’s author, I do have an opinion on this, since I assume the implementation is roughly equivalent.
In Iced, the compiler would perform a CPS transform, which would effectively infect the rest of the code from the first await call. There wasn’t a way to escape this. Once you’re in a callback, can you really get out of it? No, it’s a totally different call stack. But, when it comes down to it, any async code has the same problem in JavaScript, and developers work around it in interesting ways. A callback might not call another callback, but it’ll set a property on an object, or some other thing. In this way, callbacks feel like green threads. It’s a different stack, it can modify “shared” state, etc.
await in Iced didn’t really give you that ability by default. Once you bought into it, you were in it. Your code appeared sequential, in much the same way writing Go feels. Operations that block yield to the scheduler right there and now, and come back to the same point when the operation completes. It’s much easier to reason about, and much nicer to read and collaborate on. You can still “start” other “green threads” and interact with callback based libraries, but you’ll quickly want to use them with await, and will be better off in doing so.
And, naturally, it takes time to get used, get a feel for, and eventually even prefer.
I have no skin in this game, as I’m not a serious JavaScript developer, even on a part-time basis. However, as an early adopter of IcedCoffeeScript, since I worked with it’s author, I do have an opinion on this, since I assume the implementation is roughly equivalent.
In Iced, the compiler would perform a CPS transform, which would effectively infect the rest of the code from the first await call. There wasn’t a way to escape this. Once you’re in a callback, can you really get out of it? No, it’s a totally different call stack. But, when it comes down to it, any async code has the same problem in JavaScript, and developers work around it in interesting ways. A callback might not call another callback, but it’ll set a property on an object, or some other thing. In this way, callbacks feel like green threads. It’s a different stack, it can modify “shared” state, etc.
awaitin Iced didn’t really give you that ability by default. Once you bought into it, you were in it. Your code appeared sequential, in much the same way writing Go feels. Operations that block yield to the scheduler right there and now, and come back to the same point when the operation completes. It’s much easier to reason about, and much nicer to read and collaborate on. You can still “start” other “green threads” and interact with callback based libraries, but you’ll quickly want to use them withawait, and will be better off in doing so.And, naturally, it takes time to get used, get a feel for, and eventually even prefer.