Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

99% of the use cases that ought to use async are server-side web services. If you're not writing one of those, you almost certainly don't need async.


Or desktop programs. Many GUI frameworks have a main thread that updates the layout (among other things) and various background ones.


Async and GUI threads are different concepts. Of course most GUIs have an event loop which can be used as a form of async, but with async you do your calculations in the main thread, while with GUIs you typically spin your calculations off to a different thread.

Most often when doing async you have a small number of tasks repeated many times, then you spin up one thread per CPU, and "randomly" assign each task as it comes in to a thread.

When doing GUI style programming you have a lot of different tasks and each task is done in exactly one thread.


Hmm I would say the concepts are intertwined. Lots of GUI frameworks use async/await and the GUI thread is just another concurrency pattern that adds lock free thread exclusivity to async tasks that are pinned to a single thread.


Async for GUIs is also nice. Not essential, but allows you to simply lot of callback code


Note that if you "just" write responses to queries without yielding execution, you don't need async, you just write Sync handlers to an async framework. (Hitting dB requests in a synchronous way is not good for your perf though, you better have a mostly read / well cached problem)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: