3 ms·
Also there is the extra software development and maintenance cost due to coloured functions that async/await causes https://journal.stuffwithstuff.com/2015/02/
by miohtama 3y ago
Also there is the extra software development and maintenance cost due to coloured functions that async/await causes
https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ https://journal.stuffwithstuff.com/2015/02/01/what-color-is-...
Unless you are doing high scalability software, async might not be worth of the trade offs.
- nine_k 3y agoIf you expect to color your functions async by default, it's really easy to turn a sync functuion into a near-zero-cost async, a Future that has already been resolved at construction time by calling the sync function. This way, JS / TS becomes pretty comfortable. Except for stacktraces, of course.
- yencabulator 3y agoExcept when your sync function calls a function that makes the async runtime deadlock. No, there's no compiler error or lint for that. Good luck!
- ngrilly 3y agoUseful stacktraces is one of the reasons why I use Go instead of JS/TS on the server-side.
- RReverser 3y agoJS has proper async stacktraces as well, or do you mean something else?
- ngrilly 3y agoYou're right. But it was not the case years ago when my team evaluated Go and Node.js. I should have clarified.
- laggyluke 3y ago> Useful stacktraces is one of the reasons why I use Go I'm not sure if this is sarcasm or not.
- ngrilly 3y agoFair enough. The context is that years ago, my team was evaluating Go and Node.js as options for a server requiring concurrency, and back then Node.js didn't provide any stacktrace for async callbacks. I know it has been improved since then, but I don't use Node.js. What do you miss in Go's stack traces?