nivviv
Despite doing a lot and having a lot of smaller moving parts, the mp infra is of moderate code size and build complexity is not a concern. The whole thing compiles in less than 5 minutes, and can be done with nimble (the package manager). We have a docker builder image that spits out the final production image containing the apps, and a docker-compose setup then runs those as needed.
Any kind of per-platform specifics are handled in nim itself (when defined(Linux): etc) and via nim.config/nims.nim, to link in platform libraries.
Our particular design is a bunch of single-threaded apps on a message bus. Each app (network ingress/egress, data handling, relays, etc) sits on the bus, and can use async/await to do IO concurrency, but on the app level, there's no threading and no locking to observe.
Each app also has a erlang-inspired supervisor task system, where each task is just a async proc kept alive. It's proven to be very robust (from the standpoint of service availability) in the face of bugs or input validation mishaps.
Personally, I develop on Mac and it runs natively there the same as on Linux.
Windows binaries for the tooling releases I used to build with a cross-compiler, but more recently, GH actions looks attractive enough to take that role.
Edit: Sorry, could have been clearer. The build system is just running the binary directly via nim cpp -r in development, and for production it's nimble. The dockerfile is handcrafted, but of trivial complexity.
The PoC was incredibly quick to manifest, and iterating on it had quickly proven itself as a good way forward.
Peace of mind was a judgment call. Despite being a rather sizeable project now, what we had back then was already very stable and reliable (even under heavy benchmark load) and there weren't any great unknowns souring making the call.
Even with the rather oldschool approach of echo/logging.nim usage, things tend to turn around quickly. I have not felt the need to be able to attach a debugger to the process, mostly because our architecture is very pluggable. Almost all events/interactions are on a message bus and can be hooked/handled individually.
We (Beamdog) are using nim in production for Neverwinter Nights: Enhanced Edition, for the serverside parts of running the multiplayer infra.
nim is uniquely good in providing an immense amount of value for very little effort. It gets _out of my way_ and makes it very easy to write a lot of code that mostly works really well, without having given me any serious traps and pits to fall into. No memleaks, no spurious crashes, no side-effect oopses, anything like that. It's C/++ interop has been a huge enabler for feature growth as well, as we can partly link in game code and it works fine. For example, our platform integrates seamlessly with native/openssl/dtls for game console connectivity. And it all works, and does so with good performance. It is all now a set of quite a few moving components (a message bus, various network terminators, TURN relays, state management, logging and metrics, a simple json api consumed both by game clients and web (https://nwn.beamdog.net), ...).
We're still lagging behind and are on 1.0.8, but that is totally fine. It's tested and works, and there's no real incentive to move to 1.2 or 1.4 - yet!
Usage for our game has expanded to provide a few open source supporting utilities (https://github.com/Beamdog/nwsync) and libraries (https://github.com/niv/neverwinter.nim/) too. The good part about those is that they are cross-platform as well, and we can provide one-click binaries for users.
OTOH, There's been a few rough edges and some issues along the way. Some platform snafus come to mind, but those have been early days - 0.17, etc. Some strange async bugs had been found and fixed quickly though.
Good and bad, at least for me, nim has been a real joy to work with. If I had the chance to message my 3-years-younger, I'd just say "yea, keep going with that plan", as it turned out to save us a lot of development time. I suspect the features we've put in wouldn't have been possible in the timeframe we had, if it would have been all written in, say, C++.
A project that injects via LD_PRELOAD into a game called Neverwinter Nights (now Enhanced Edition). It lets content authors/admins add things like database support, more scripting languages, extensive ruleset changes, and whatever else you want to the game.
docker id: nivviv