> So the question could be: whats the audience/usecase for async/await - > feature vs threads? new Nim users could be confused about that (like me). > > I don´t think it´s a good idea to "marry" both - but that´s just my humble > 2cts..
Sorry to be cheeky, but, New Nim users (and programmers in general) need to learn the difference between concurrency and parallelism. :-P This is a common confusion. Async and Threads are different design patterns that solve different problems. The problems they solve look similar on the surface, which is why people get confused. * Threads: Literally running two different pieces of code in parallel at the same time, on two physically different CPU cores. * Async: A design pattern that lets a **single** CPU core continue to do work without having to wait for slow things like network connections or hard drive I/O to finish (known as _blocking_ ). An example of where you would use threads: "I need to sort a large array, so I am going have a bunch of cores each sort a small piece of that array, all at the same time, so it finishes faster." An example of Async is: "I need to read this file. Instead of putting the whole thread to sleep to wait for the hard drive to give me the file, I'm going to pass off control to another function to do some work, then just wake me up when the file is ready." The thing is, (usually for advanced cases), you may want both patterns. A web browser is a good example of this: * You could have an async GUI thread that handles your button clicks, typing, and other user input... This is all async code that responds to user input events. * Then you have a different thread that is doing complicated parsing (CSS and HTML) and rendering the final image. You need the two threads to talk to each other though. In this case, you want a nice API for your GUI code to talk to the render thread, (which might be busy parsing, so it can't talk right now). The GUI thread is async, it doesn't want to stop and wait for the other thread (and make your browser unresponsive). An async channel solves this problem. You send the other thread a message on the channel, then _await_ , and let some other function take over and do other work (like respond to the user typing), then wake up again when the other thread finally sends a response back.
