Couple days ago I started evaluating Nim for the server side. I already used Nim for half a year, for data processing, it works well, so I decided to also use it on the server. The project is not critical, yet it's important enough so the server should work more or less reliably and be relatively performant.
Nim support **Threads, Async and Weave and CPS** via third party libraries. Unfortunately, it seems like **right now none of it could be used** to build simple, reliable and performant web server. After couple of days trying to understand parallel Nim, I still don't feel like I understand how to use it. Parallel support in Nim feels fragile, experimental, unfinished and buggy. Compared to learning experience in Java / Ruby / Elixir / Node - after a day or two you know pretty much everything you need to build web server and are ready to go. Problems: **Async** While I personally don't like async as [it has some problems](https://forum.nim-lang.org/t/7583#48122), but ok, seems like that's the official Nim way, and I just have to accept it. How to read/write some data from/to the file? You just use `open/read/write` file operations from the `std` you already know, right? Wrong. They can't be used because they are not `async`, you need to learn a special async API like `std/asyncfile`. That was unexpected. I use one library (sync library) in my data processing code, but for the web server code I can't use it and should spent time learning something else? And what about lots of my custom functions that are written in sync style? Seems like I can't use it too. And you can't use third party libraries like DB API etc. that are not async. So **no code reusability, code can 't be shared easily**. It is worse than Node.JS, as in Node.JS all IO functions are async, no matter if used in plain scripting or web server, so you use same functions everywhere. Another red flag, that pretty much makes Async unacceptable for any production server is **ability to accidentally block the event loop**. Use some non-async IO call in any server handler, accidentally, and the whole server and all other request will block until that handler is finished. You deployed changes with non-async function to the server, tested it on staging seems ok, then deployed to prod - and the server became unavailable. Because the problem didn't manifested itself on staging as that specific route with sync IO has not been hit there, but it was hit in production. Or, you paid good money for ads, the traffic increased x10 times, but your server unexpectedly slowed down, providing terrible experience for users and wasting your ads money. Because of some sync function, that was invisible with usual load but manifested itself during x10 traffic boost. Such problem is not possible in Node.JS because there's no sync IO functions (and sync CPU-intense functions are usually rare). That pretty much means that you **can 't use Nim Async if you care about reusable code and reliable and performant server**. **Threads** It seems that it works more or less well. But nobody uses it, there's no popular web servers with thread support, and everyone discourage using threads and advises to use async. Also, there is the documentation, but it still leaves lots of blank spots, and there are surprises with compiler complains about GC-safety and Closure not supported, etc. And lots of different GC-modes and ways to deal with threads just adds to confusion, so in the end you have no clear understanding how to actually use Threads in Nim. 3 Weave and CPS Weave - is a specialised solution, not designed for web server like load. CPS - experimental, not ready for usage. All that pretty much means that currently Nim is not ready to be used on the server side.
