> Depends on the architecture. Of course it does. This is why I said "For the vast majority ..."
> Async code can become very complex too and arguably is more complex than > dealing with threads. Sure, but I once again repeat what I wrote above. For the majority of use cases async is the simpler choice. > > Furthermore I don't think you can just use threads and call it a day for > > your web service. Spawning a thread per request won't scale. You need > > lightweight concurrency which is what async/await in Nim is. > > Nobody proposed that, a thread pool is used when you use spawn. The proposition boils down to "no async only threads". So how can you write a web service with just threads? You need a thread per request. There is no other way. > I'm a compiler developer. The Nim compiler is CPU bound. The compiler might > be run online, see the Nim playground. The last thing I want to do is to add > async and await calls for things that may "block". For various reasons. Yeah, the Nim playground runs fine and has no need for async to be added to the Nim compiler. So what's your point?
