One of the reasons for choosing Nim was the ease of getting a production ready web backend. For the core part of managing the backend we are using existing Nim

One of the reasons for choosing Nim was the ease of getting a production ready web backend. For the core part of managing the backend we are using existing Nim libraries [1], and they are easy to expand and work with. I cannot give you a comparison with Go since I haven't managed that large Go projects - but for Nim we are all into the async and threading. I think the channels within the threading is hardest part in Nim, but work is being done it. [1] https://nimble.directory https://nimble.directory [1a] https://github.com/dom96/jester/ https://github.com/dom96/jester/ [1b] https://github.com/planety/Prologue https://github.com/planety/Prologue [1c] https://github.com/guzba/mummy https://github.com/guzba/mummy