At work, our first success in this vein was migrating a Python Twisted service to Go. Due to the critical nature of this service, we strove for feature parity. We ended up with a mostly Go-like code base, but it was very similar to the original code base in basic structure. Most of the improvements we got were due to the language choice, not due to a better design.
Our main concern is concurrency, and for that Go excels. Additionally, post re-write, that code base is easier to follow, easier to extend and maintain, easier to deploy, easier to control lower level aspects, and much, much more performant. It was years ago at this point, but I believe our improvement was something like 120x.
Since then, at work, we've moved to Go as our main language for services. This has provided even more wins as we continue to move legacy Perl/AnyEvent code over. With new rewrites (and new projects), we are taking the opportunity to also redesign systems, enabling our software to scale even further. We have lots more to do and we are hiring :)
Our main concern is concurrency, and for that Go excels. Additionally, post re-write, that code base is easier to follow, easier to extend and maintain, easier to deploy, easier to control lower level aspects, and much, much more performant. It was years ago at this point, but I believe our improvement was something like 120x.
Since then, at work, we've moved to Go as our main language for services. This has provided even more wins as we continue to move legacy Perl/AnyEvent code over. With new rewrites (and new projects), we are taking the opportunity to also redesign systems, enabling our software to scale even further. We have lots more to do and we are hiring :)