A small perspective insight from a game developer:

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++.

Interesting, thanks for sharing.

May I ask, did you consider Go and decided against it for any reason considering your requirements of quick development, cross-platform, interoperability are all guaranteed features of Go which should have given better peace of mind considering a production application?

Go code runs much more slowly than Nim code in my experience. Nim realizes better ergonomics than Python in some ways (UFCS, command syntax, user-defined operators) and as good performance & lightweightness as C/Rust.

I'm honestly surprised Nim is not the secret weapon of many start-ups. Nim is much more "open architecture" instead of pushing some "single, canned turn-key fits most users" solutions.

Having a juggernaut like Google marketing/pushing/subsidizing something might provide false as well as true peaces of mind. :-) { Such peace is a multi-dimensional concept. :-) }

Statement on performance is surprising, I haven't personally benchmarked Nim against Go so couldn't say about that.

But I started using Go for the same reasons pointed out in parent and after being tired of changing Python code to C to resolve performance issues.

How about concurrency?