<p>I'm working on a native library which I'm going to write in Golang and I need to access from Python, nodejs, Ruby, Java and PHP for now at least, I may need to support other languages eventually.</p>
<p>I found this doc which shows how to make this work for the first four languages but not PHP: <a href="https://medium.com/learning-the-go-programming-language/calling-go-functions-from-other-languages-4c7d8bcc69bf">https://medium.com/learning-the-go-programming-language/calling-go-functions-from-other-languages-4c7d8bcc69bf</a></p>
<p>I've googled around a bit but haven't found any active projects for calling into shared native libraries from PHP. . . I realize this is more of a PHP question potentially and I'm going to crosspost in <a href="/r/php">r/php</a> but if anyone here has recommendations, I'd be happy to hear about them.</p>
<hr/>**评论：**<br/><br/>scottjbarr: <pre><p>How about exposing your code as a service over HTTP or gRPC?</p>
<p>I've seen Go being called from PHP before via shell commands, and the tight coupling caused a lot of problems long-term. It doesn't matter which languages we're talking about, this way always ends up sucking.</p></pre>tech_tuna: <pre><p>Yeah, I don't want to shell out if I can avoid it. This code needs to run in the context of a web server. . . Django, nodejs, RoR etc. and I need to support PHP frameworks too.</p>
<p>So I need to be able to call my compiled Go code from a PHP app server. A locally running gRPC/http service could work but I'd rather not deal with spinning up an additional service on a local machine - it may be difficult to do as this code needs to run on environments I don't control - difficult from the IT/operations side of things.</p>
<p>EDIT: on second thought, it might not be such a pain doing something like this: <a href="https://www.reddit.com/r/golang/comments/6xwc75/anyone_know_a_good_way_to_call_golang_library/dmixig0/?context=3" rel="nofollow">https://www.reddit.com/r/golang/comments/6xwc75/anyone_know_a_good_way_to_call_golang_library/dmixig0/?context=3</a></p></pre>epiris: <pre><p>I wouldn't consider any other approach then exposing Go as a service honestly. If you implement a native client for every single language (ruby, php, python, ..) have a completely different system for native extensions / modules. Native modules will be different across different versions of those languages, multiply that possibly by different platforms, THEN potentially by various language runtime containers (for PHP you use to have the SAPI which provides different memory ownership models and constraints vs the CLI) and all the quirks with endianness and so on.</p>
<p>This is before you even started to write any Go and typed import C; after that you have to deal with making a interface that can hold up to the hostility of all the various callers. I imagine you will end up making several Go packages to write your primary business logic to satisfy the diversity in interfaces provided by the native clients. I promise that you will without a doubt spend 99.99% of time your time very annoyed debugging EVERYTHING except the Go code you wrote. To add insult to injury your users don't want to use native client libraries either. I'm sure you don't like to pip install a python module and see swig pop up with 400 lines of red gcc errors.</p>
<p>Make a service. Have the service listen on a addr. Let addr be a unix socket or URL. Finally use GRPC to spin up a server and have a client maintained for EVERY language by google and GRPC contributors for free, that your users may ALREADY be importing and familiar with. They also have the freedom then to start your Go binary anywhere, docker containers on TCP, bare metal unix socket, put it on a separate pair of machines all together, start it up on their own local dev boxes for testing, etc.</p>
<p>Just food for thought. gl either way.</p></pre>vvivien: <pre><p>If PHP has an efi library that can call c-style functions then you should be able to do that. I didn't look into PHP but will and update that write up you referred to above.</p></pre>tech_tuna: <pre><p>Oh wait, you wrote up that medium.com post?</p>
<p>EDIT: just looked at your history, it was you! Wow, thank you so much for that article, it's super helpful!</p></pre>vvivien: <pre><p>Yes!</p></pre>tech_tuna: <pre><p>Nice. It's times like these when I really appreciate reddit and the Internet.</p>
<p>:)</p></pre>titpetric: <pre><p>Haha, he wrote it and & contributed the LUA part ;)... we're all here</p></pre>tech_tuna: <pre><p>One big Golang party!</p></pre>steffen25: <pre><p>Hey I remember someone posted this a while ago </p>
<p>High-performance PHP-to-Golang RPC bridge
<a href="https://github.com/spiral/goridge" rel="nofollow">https://github.com/spiral/goridge</a></p></pre>tech_tuna: <pre><p>Interesting. . . I'd still prefer the native library approach if I can find a good/clean solution. Thanks.</p></pre>djhaskin987: <pre><p>"When in doubt, shell out". Build a CLI using golang and <a href="https://github.com/spf13/cobra" rel="nofollow">cobra</a>. Then call the CLI using a PHP <a href="http://php.net/manual/en/function.system.php" rel="nofollow">system call</a>.</p></pre>tech_tuna: <pre><p>Ha ha, yep that's my fallback plan. :)</p></pre>djhaskin987: <pre><p>Ah. reading a little closer, I see the article is talking about compiling the go code into something that looks like a C shared library, then calling the library as if it were written in C. They do it that way because all sorts of languages support calling native (C) shared libraries. PHP supports this via <a href="http://php.net/manual/en/internals2.ze1.zendapi.php" rel="nofollow">Zend</a>, but it means you'll have to build a module to extend PHP.</p></pre>tech_tuna: <pre><p>Right, probably obvious but I'm looking for a clean and simple solution which doesn't involve a complicated build system. Golang makes this a lot easier because I can cross-compile for different operating systems (from one build host) easily. </p>
<p>I need Linux support right now but might need to support Windows too. Also, I prefer Golang to C/C++ for plenty of other reasons. :)</p></pre>titpetric: <pre><p>PHP doesn't have a FFI, but LUA does, and <a href="http://php.net/manual/en/book.lua.php" rel="nofollow">LUA is available as a PHP extension</a>. While I haven't used PHP and LUA in this way, I did actually <a href="https://github.com/vladimirvivien/go-cshared-examples#from-lua-contributed" rel="nofollow">contribute the LUA example</a>. Technically you might need LUA JIT which PHP might not have (there's a C toolchain behind it...)</p></pre>tech_tuna: <pre><p>Interesting. . . thanks for the info.</p>
<p>I did find this which seems like my easiest/most viable option atm: <a href="https://github.com/kitech/php-go" rel="nofollow">https://github.com/kitech/php-go</a></p></pre>titpetric: <pre><p>Perhaps <a href="https://github.com/mgdm/MFFI" rel="nofollow">https://github.com/mgdm/MFFI</a> or <a href="https://github.com/m6w6/ext-psi" rel="nofollow">https://github.com/m6w6/ext-psi</a> would work for you. Even with a 1y+ commit date, MFFI could be stable on the usual PHP versions, unless you want to run cutting edge PHP >7.0 stuff I guess. The module system doesn't get changed as often as PHP versions get released, I think it only changed twice during the 5.x branch. Mileage may vary.</p></pre>
