I’m a huge fan of stuff like this, however it’s not strictly true that features like this are “opt in.” If you write your code alone and in a vacuum, it’s opt-in. However, if you write your code on a team, if you use NPM packages that were compiled from this code, if you use backbone extensions compiled from this code, you’re opted in “by proxy” to the code it produces whenever you find yourself stepping through the code in a debugger or reading the compiled code in a browser environment.
IMO, it could be a win by virtue of producing consistent code for the most common cases. It may seem unfamiliar at first compared to the code you would personally write, but if it becomes a standard and everybody’s code ends up looking much the same, that’s a win overall.
I think this is already true for binding functions to the current ‘this’ and for comprehensions, and we could use a standard ‘pattern’ for the resulting asynchronous code for most common cases.
But I grant that it isn’t purely optional in a world where very few people write their own stack in its entirety.
Ever since I wrote this I realized that this feature, as outlined here, is not opt-in, even in a vacuum, due to the fact that will break all variables named 'await' and 'defer'.
About using others' code: compile time code generation is always possible, and you can't prevent the libraries you are using from using it. It can even be worse: they can runtime code generation, or a downright obfuscator.
Since more and more languages are being compiled to JS (Clojurescript being one formidable recent addition), trying to stay "pure" with respect to the libraries you use is getting harder and harder.
My biggest worry is that Coffeescript starts stagnating from lack of innovation (which seems to affect most stable languages).
One way Scala managed to experiment with features while still trying to be stable, was through Scala Compiler Plugins[1].
This we could be having a less theoretical conversation, by throwing it in the wild, and learning from the experiments people make with it.
IMO, it could be a win by virtue of producing consistent code for the most common cases. It may seem unfamiliar at first compared to the code you would personally write, but if it becomes a standard and everybody’s code ends up looking much the same, that’s a win overall.
I think this is already true for binding functions to the current ‘this’ and for comprehensions, and we could use a standard ‘pattern’ for the resulting asynchronous code for most common cases.
But I grant that it isn’t purely optional in a world where very few people write their own stack in its entirety.