The actual reason is much less exciting than you might have hoped and actually has nothing to do with erlang vs golang...<p>The erlang version has been running successfully for about 2 years and we haven&#x27;t had any issues whatsoever (excepting a wrestling match with mnesia early on). We are erlang&#x2F;elixir advocates and have used the erlang vm successfully on highly critical multi-million-concurrency services for over 6 years.<p>When we set out to build nanobox desktop (<a href="https:&#x2F;&#x2F;desktop.nanobox.io" rel="nofollow">https:&#x2F;&#x2F;desktop.nanobox.io</a>) our vision was to provide a single pre-compiled executable that could be run without any configuration. The design required a push layer and needed the same functionality that the erlang project was already providing. It wasn&#x27;t feasible to package the erlang application into the nanobox binary, so we emulated the original project into a consumable golang package. As time went on we were porting more and more of the features into the golang port until all that was lacking was distribution and authentication. At that point we made the decision to consolidate our efforts into a single project, that could be a standalone service or composed within a golang binary.<p>I regret to inform you that there isn&#x27;t a mass exodus within our company to ditch erlang for golang. While that certainly would make for a fun thread, in this case it was simply a matter of fit and effort consolidation.