
Migrating Passenger from C++ to Go? - ValentineC
https://blog.phusion.nl/2018/09/18/migrating-passenger-from-cxx-to-go/
======
RcouF1uZ4gsC
Another alternative is to migrate to Modern C++. I just did a quick look
through the code base.

[https://github.com/phusion/passenger/blob/stable-5.3/src/cxx...](https://github.com/phusion/passenger/blob/stable-5.3/src/cxx_supportlib/Crypto.h)

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](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/](https://think-async.com/) and asio is
tracking the evolving standard. Most new C++ networking libraries are also
standardizing on asio.

------
MarkMc
> JVM has very limited integration possibilities with an existing C++ codebase

Java has JNI. How does Go improve on that?

~~~
colek42
You can statically compile your go and c code into a single binary.

------
cryptos
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.

------
sadjfoadsf
C# and call it a day.

~~~
hactually
>>>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

