As a beginner I do need some clarification (rel. Perl and Shell script in general)

<p>Hi,</p> <p>I&#39;m currently working on a homeautomation system which is based on Perl. Certain events (within the system) trigger standalone Perl scripts, which then communicate via a TCP-Socket with e.g. my touch screen in the corrdior. The other way around, inputs from my touch screen are sending a message to the TCP-Socket and then a Perl-Script is setting up stuff (via HTTP-Requests, though) in the homeautomation system. Imagine simple Perl-Scripts which are just started from Terminal commands and quit after execution. It&#39;s really simple (connect to TCP, send a message, close connection, quit).</p> <p>I&#39;m a bloody beginner when it comes to script languages (I do develop in JS/AS3/Swift/Obj-C), so I&#39;m pretty much in need of ELI5 for anything. Perl gave me a good kickstart and I was able to prototype my ideas within some hours. It&#39;s horrid code and I&#39;d never show it anybody, but it does work for my purpose <em>so far</em>. I&#39;m already hitting walls, though, and can&#39;t imagine sticking with Perl for long when it comes to more complex tasks (I already am having troubles to figure out how to pass an Object). Also I&#39;m missing everything related to OOP and structures in general. </p> <p>Everyone I&#39;ve told about it was telling me to go down the Python road. And I started reading about Python. If I&#39;m correct I could just call Python scripts from Perl and therefore just have to rewrite my custom scripts (and not the homeautomation server). Would be an idea. Now I&#39;ve met some people who told me to check Go. And almost everybody said: Yes, go Go, it&#39;s fast, reliable, modern and well settled for the future. So I&#39;ve read a little about Go but I&#39;m stuck with even the most simple questions. </p> <p>I understood that Go needs to be compiled and then ends up with being a native application I can run via Shell (so far so good, just like Perl). But am I able, like, do I get to hell, if I write &#34;mini&#34; applications which just do their one task and get killed afterwards while I have one TCP-Server, written in Go, which is running permanently and taking care of the rest? Or is there a way to communicate with a running Go application via.. yeah, via what? Shall I send a message with a Perl script to a running Go application just to trigger its functionality?</p> <p>Thanks in advance and excuse the stupidity that comes along my questions.</p> <hr/>**评论：**<br/><br/>barsonme: <pre><p>Two ways you could communicate with a running Go binary: using some sort of API over http or using RPC.</p> <p>But are fairly straightforward. Take a look at the net/http and rpc packages. </p></pre>Tsupaero: <pre><p>Thanks, good starting point. I&#39;ll have a look at them!</p></pre>the_jester: <pre><p>You can write very small programs in Go and call them repeatedly; they can be initiated and/or terminated without major. Because Go is compiled and lean there isn&#39;t a substantial wait for a virtual machine to start up each time. You do not have to be scared of treating them like &#39;scripts&#39; in that regard.</p> <p>Communication between running programs is a common, common need. It is resolved different ways depending on the situation, and every general-purpose programming language has several possible answers, Go is no exception.</p> <p>One of the simplest, and from your description, possibly most appropriate for your situation is to have shell script(s) calling your program(s) and supplying them with arguments. This method works regardless of if you have written your scripts in Perl, Go, or most any other language. If your server was going to be triggered on simple criteria (once a minute, do X), then <a href="http://www.tldp.org/LDP/Bash-Beginners-Guide/html/Bash-Beginners-Guide.html#chap_02" rel="nofollow">Bash</a> and <a href="https://en.wikipedia.org/wiki/Cron" rel="nofollow">Cron</a> would be all you need in addition to your collection of simple perl/go programs.</p> <p>Another way to fulfill exactly the architecture you&#39;re imagining is <a href="https://www.cs.cf.ac.uk/Dave/C/node33.html" rel="nofollow">RPC</a>. You would write your &#34;mini&#34; applications to expose a <a href="https://golang.org/pkg/net/rpc/" rel="nofollow">RPC interface</a>, and then they would stay running all the time. When you wanted them to actually do something your server would call them via RPC to trigger it.</p> <p>Depending on how your home automation things are connected, you can also use wireless protocols like <a href="https://github.com/ninjasphere/go-zigbee" rel="nofollow">ZigBee</a> directly in go instead of RCP over TCP/IP.</p> <p>For a much more &#34;heavy weight&#34; connection, you can do what virtually all web applications do: communicate via a database. Your server would put rows into a &#34;tasks&#34; database (for example), and your &#34;mini programs&#34; would query the database periodically and take action based on what they get back.</p></pre>Tsupaero: <pre><p>Thanks for the well explained answer. I&#39;ll have a look at what you&#39;ve suggested and it definetly helped me to get a grasp on it. Thanks!</p></pre>