> For the vast majority of web projects threads actually just add unnecessary > complexity leading to poor reliability.
@dom96 Disagree, from my experience, workning with Ruby and Elixir is much easier than with Node.JS. For classical web projects like this forum, if say Ruby is used, developer would never explicitly see any concurrency/paralleism related constructs, everything would be done automatically. Best code is when there's no code. There are cases where threads can't be used, and async (or Actor, CSP) would be needed. For example for chat application (10k connection problem), but such projects are rare. > 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. > ... > 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. @dom96 Please see the text below about Nginx+Worker like architecture for the server. > Are you aware of GuildenStern, the Modular multithreading Linux HTTP server > written in Nim? @Allin thanks, interesting, seems like it's what I want: evended requests receiver + thread based pool of workers. > I picked a real world example aligning well with alexeypetrushin's > requirements: > > \- Code is developed synchronously first. > \- Code is then > migrated to run on a server, rewriting code is expensive. > \- Even if a > rewrite is feasible, all your dependencies need to run asynchronously too. @Araq yes. > I'm happy to advise further if you give some more specific requirements of > what you're trying to achieve dom96 thank you Dominik, your help and the help of Nim community, answering lots of my questions was very valuable, I really appreciate it.
