3 ms·
It's interesting that JS is still trying to figure out ways to make callback-based asynchronicity less-painful while Go managed to skirt the issue altogether. G
by weberc2 10y ago
It's interesting that JS is still trying to figure out ways to make callback-based asynchronicity less-painful while Go managed to skirt the issue altogether. Go is readable, asynchronous and parallelizable largely without callbacks of any kind. Of course Go has its own problems, but I think they're largely orthogonal to its async story (i.e., JS could adopt Go's async strategy without adopting Go's more controversial features).
- addicted 10y agoJS became a language it was never meant to be not because of its merits, but because it is the language of the web. Go is the language it was always meant to be, and a significant part of that was handling async. Once async/await comes along, JS will have a really nice solution, and to be honest, I think it's pretty impressive that JS, with the history of its development, has been able to acquire new technologies of this nature.
- weberc2 10y agoAsync/await will be an improvement to be sure, but I think it still leaves a lot to be desired. In particular, I'm not a fan of bolting (a)synchronicity onto the function definition; instead, it's nice to be able to run a function in either a sync or async context. But yes, props to JS for continuing to improve.
- nickik 10y agoClojureScript compiles to JavaScript and you can have the exact same CPS style programming, with the exception of missing parallelism of course. Async/await are not really what you want either. There is no fundamental reason JS could not have added a CSP model.