5 ms·

A small perspective insight from a game developer: We (Beamdog) are using nim in production for Neverwinter Nights: Enhanced Edition, for the serverside parts

by nivviv 6y ago

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 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 https://github.com/Beamdog/nwsync) and libraries (https://github.com/niv/neverwinter.nim/ 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++.

Abishek_Muthian 6y ago
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?
- nivviv 6y ago
  Go was a consideration and there are a few libraries internally existed for Go at that point, but nim in the end won out on acceptance and it convinced - despite the known risks of using a only semi-mature language - on feasibility in getting it done in time for the initial game release. 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.
- cb321 6y ago
  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. :-) }
  - Abishek_Muthian 6y ago
    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?
    - cb321 6y ago
      There is a link in another of my comments here and because Nim is pretty open architecture you can roll your own basis for what you want (more than most languages) such as: https://github.com/mratsim/weave https://github.com/mratsim/weave
      - 6y ago
tylorr 6y ago
What's the dev experience been like? Do you feel like there is good editor support for debugging and such?
- nivviv 6y ago
  I've been using vscode+nim. Debugging was mostly just writing correct code in the first place! ;) The only gripe I have is sometimes nimsuggest hanging itself at 100% cpu use, and I have to kill it manually. 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.
  - jimbob45 6y ago
    What build system are you using if not MSBuild then?
    - nivviv 6y ago
      Our production stuff runs on Linux, so we just wrap it into docker and that's that. 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.
      - jimbob45 6y ago
        So you use Docker to keep the build system unchanged between builds? That’s genius if so and cuts deeply into MSBuild’s main advantage (comprehensively delineated system settings).
        6y ago

by nivviv 6y ago

Abishek_Muthian 6y ago

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?

nivviv 6y ago
Go was a consideration and there are a few libraries internally existed for Go at that point, but nim in the end won out on acceptance and it convinced - despite the known risks of using a only semi-mature language - on feasibility in getting it done in time for the initial game release. 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.
cb321 6y ago
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. :-) }
- Abishek_Muthian 6y ago
  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?
  - cb321 6y ago
    There is a link in another of my comments here and because Nim is pretty open architecture you can roll your own basis for what you want (more than most languages) such as: https://github.com/mratsim/weave https://github.com/mratsim/weave
    - 6y ago

tylorr 6y ago

What's the dev experience been like? Do you feel like there is good editor support for debugging and such?

nivviv 6y ago
I've been using vscode+nim. Debugging was mostly just writing correct code in the first place! ;) The only gripe I have is sometimes nimsuggest hanging itself at 100% cpu use, and I have to kill it manually. 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.
- jimbob45 6y ago
  What build system are you using if not MSBuild then?
  - nivviv 6y ago
    Our production stuff runs on Linux, so we just wrap it into docker and that's that. 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.
    - jimbob45 6y ago
      So you use Docker to keep the build system unchanged between builds? That’s genius if so and cuts deeply into MSBuild’s main advantage (comprehensively delineated system settings).
      - 6y ago