IS GO [GOLANG] SUITABLE FOR ALGORITHM DEPLOYMENT?
Before I tell a story about how I ported the front-end of my C-based Reed Solomon algorithm demo to go [golang], and post the results, I will answer the obvious.
Yes, go is suitable for algorithm deployment. Enterprises deploy algorithms in Python, so clearly go is suitable: its syntax is a blend of C and Python, and it is a relatively fast compiled language. Moreover, it's easy to inline existing C code and libraries, which is what we show below. The performance penalty of calling C from go is minimal.
Linking and Inlining C (Good)
So, I went through the trouble of porting the demo front-end into go directly. The algorithmic backend remained as a static C library (librs.a). Including these elements into a go package is one part makefile and one part inline coding. go requires that you put the C code and build instructions in comments above the import "C" directive, but that's about it. This is nice. I can't understate how much better this is that using pymodule, JNI, or even JNA.
Handling Data that C Would Put on the Heap (OK)
go isn't explicit about heap and stack. It has garbage collection, and so forth. However, it's basically no different than using malloc() apart from not requiring the mating free() calls. Not really a big deal for an expert programmer.
Strict Typing (A Real Pain)
Good data algorithms are not built around the idea of strict types, they are built around the idea of transforming a pile of bytes into another pile of bytes. I understand why the go designers kept-out soft typing (and in fact made go very pedantic about typing), but in certain cases it's just silly. Perhaps the best example of the silliness, here, go's inability to use arithmetic conditionals.
Performance Results, and Indications of Call Overhead
go has some overhead when it calls C, but not much. I ran these demos a bunch of times, at different times of the day, and the results were consistent -- there's a subtle overhead of using go to call C, even when using "unsafe" pointers when calling C.
You'll notice that the actual timed part of the loop is just one call, and it doesn't pass-back any data. So what we are observing in the minimal call overhead. It amounts to a few percent (4-7%). It's absolutely great that it's so easy to do "unsafe" calls to C, though.
XLP Capital is a family office and as such is not required to be registered as an investment adviser with the U.S. Securities and Exchange Commission. Investments are made available only to accredited, qualified, or institutional investors that are eligible as family office clients, pursuant to the rules of the U.S. Investment Advisors Act of 1940. XLP does not seek or solicit investment for these funds or any other funds, and nothing on this page should constitute a solicitation for investment. The descriptions on this page is provided for information value only, as examples of prior investment related work XLP has conducted. XLP Capital assumes no liability for investment losses direct and indirectly resulting from recommendations made, implied, or inferred by its research. Likewise, XLP Capital assumes no claim to investment gains direct or indirectly resulting from trading profits, investment management or advisory fees obtained by following investment recommendations made, implied, or inferred by its research. Investment involves risk, and all investments should be made with the supervision of a professional investment manager or advisor. The materials on the Website are not an offer to sell or a solicitation of an offer to buy any investment, security or commodity, nor shall any security be offered or sold to any person, in any jurisdiction in which such offer would be unlawful under the securities laws of such jurisdiction.