It does not use RAII to manage resources, instead there a a bunch of raw pointer with sizes and a manually called free function
void freeAESEncrypted(AESEncResult &aesEnc);
Just from this brief look, it does not at all surprise me that the development velocity is suffering.
Joel's article on why you should never rewrite software is worth mentioning. There is probably a lot of institutional knowledge that is embedded in the code which will be lost if you convert to Go.
That way you always have a working product, that has the features and performance that people have come to expect, while at the same time you are eliminating technical debt and increasing development velocity.
In regards to the question about networking libraries all conflicting with each other, it is about to get better. The C++ committee will standardize a C++ Networking library in the near future. The good news is that it is based on asio https://think-async.com/ and asio is tracking the evolving standard. Most new C++ networking libraries are also standardizing on asio.
I don't get the point with Java feeling slow because of the slow start time (compared to C++). If I understand correctly Passenger is a server application and this kind of application is typically started rarely and long running, so the start time is a non-issue in most cases.
Another option could have been Swift, what is a more powerful language compared to Go.
>>>We never considered Java/JVM because although it's high-performance, it doesn't feel fast: slow boot times, high memory usage. These factors are all malleable to a degree (e.g. JVM client mode allows faster boot times, memory usage depends on GC tweaks) but I've never seen a JVM application to be tweaked in such a way that it feels as snappy as a C++ application. To users, feeling fast is just as important as actually being fast. And then there's also the issue that JVM has very limited integration possibilities with an existing C++ codebase.
Most of the principles apply to C# as to their Java dismissal
https://github.com/phusion/passenger/blob/stable-5.3/src/cxx...
Has some issues.
There are pointers everywhere, even a void* *
It does not use RAII to manage resources, instead there a a bunch of raw pointer with sizes and a manually called free function
void freeAESEncrypted(AESEncResult &aesEnc);
Just from this brief look, it does not at all surprise me that the development velocity is suffering.
Joel's article on why you should never rewrite software is worth mentioning. There is probably a lot of institutional knowledge that is embedded in the code which will be lost if you convert to Go.
A better alternative might be to incrementally update the code to C++17 following C++ best practices https://github.com/isocpp/CppCoreGuidelines.
That way you always have a working product, that has the features and performance that people have come to expect, while at the same time you are eliminating technical debt and increasing development velocity.
In regards to the question about networking libraries all conflicting with each other, it is about to get better. The C++ committee will standardize a C++ Networking library in the near future. The good news is that it is based on asio https://think-async.com/ and asio is tracking the evolving standard. Most new C++ networking libraries are also standardizing on asio.