What can I use for a simple IPC between Go and a program written in arbitrary lang ?

<hr/>**评论：**<br/><br/>jh125486: <pre><p>How arbitrary? gRPC seems to do well. And if that isn’t supported there’s good old fashioned JSON. </p></pre>Loves_Portishead: <pre><p>+1 for GRPC</p></pre>BadlyCamouflagedKiwi: <pre><p>What&#39;s the relationship between the two programs? If one spawns another then communication over stdin / stdout can work well - although you also need a serialisation format, JSON is likely easy and protobufs are nice for more structure.</p> <p>(Am also +1 for gRPC but you&#39;re after something lighter so...)</p></pre>lhxtx: <pre><p>gRPC is fantastic. </p></pre>holyjeff: <pre><p>grpc or json are both possible though I think they are both a bit too much. Is there a lightweight way you can recommend ?</p></pre>SeerUD: <pre><p>In what way do you mean a bit much? </p> <p>gRPC is actually really easy to use, but if you want to get simpler (though more difficult) then you could always just use a raw TCP connection and pass bytes around yourself - but why go through all of that hassle if you don&#39;t need to? gRPC will also be more lightweight than making some JSON web service too since Protobuf is a faster (to encode and decode) and more lightweight data format.</p></pre>dfndoe: <pre><p>If go is spawning the other language then json on stdin/stdout is pretty straightforward and makes for a very language agnostic interface.</p></pre>meta_leap: <pre><blockquote> <p>If go is spawning the other language then json on stdin/stdout is pretty straightforward</p> </blockquote> <p>Even when it&#39;s the other way around, too! I&#39;m quite keen on line-based IPC if the processes are all under your own development/control and are all &#34;reasonably fast&#34; with regards to eg. JSON. I struggle to find a better protocol for line-based text-based IPC ---custom stuff always seems to end up growing to the point where switching to JSON is the sane choice--- and I like line-based-text-based because one can pose as the-other-process interactively via the terminal when it becomes necessary for a bit. Also it&#39;s handy to have the 2 output channels built-in to every process, for example &#34;stdout for IPC, stderr for debug-logging to the other side&#34;.</p> <p>Performance-wise seems fine if the processes are &#34;ping-ponging structured messages&#34; between each other, rather than say continuously-streaming (where raw-bytes serializing might prove more efficient).</p></pre>