Ask HN: language recommendations for a compact, portable daemon?

[snewman]

I'm planning to build a daemon that uploads monitoring data to an online service. Customers will install the daemon on the computers they wish to monitor. I'm looking for advice on the best language / platform to use. Criteria (in roughly descending importance):

* Minimal setup hassle for our users, across all commonly used Unix (especially Linux) variants. This argues for a language for which most users will have the runtime already installed, or failing that, trivial to install from their package manager.

* Good basic libraries for filesystem and network access, including HTTP+SSL.

* Stable -- can expect to run for months at a time without hiccups or memory leaks.

* Reasonable performance -- e.g. able to read 1MB/sec of data from disk, lightly massage it, compress it, and push it to the network, with a fraction of a CPU core.

* Reasonable memory overhead. (Preferably able to run a 5000-line program, using libraries such as HTTP and SSL, and working with ~1MB of objects, in ~10MB of RAM.)

* Portable to Windows and OS/X without undue difficulty.

Anyone with experience deploying a background daemon across multiple OS configurations? Two obvious candidates seem to be Python and Java. Java would be more convenient for us, but I wonder if Python might be better for ease of installation, and perhaps memory overhead.

[skram]

Is there a reason you're writing another daemon? Have you seen http://fluentd.org/ which seems to already have packages for many OSes as well as plugins.

[snewman → skram]

Good question (and thanks for the fluentd pointer). The answer boils down to:

1. We want to provide a number of functions (e.g. tailing logs, gathering system metrics, reading from application-specific monitoring interfaces). There are packages such as fluentd and logstash that provide this type of functionality, but not all in one place.

2. As a multi-tenant SaaS offering, we have some extra requirements around authentication and security.

3. We want to absolutely minimize the effort needed to install the daemon. Ideally, for most users, the steps would be "download archive, extract archive, invoke setup script". The more dependencies (e.g. Ruby) we incur, the harder it is to keep installation clean and reliable across distros.

4. We also want to make management (starting, stopping, troubleshooting) as simple as possible. This calls for minimizing layers that might add their own log output or separate log files, separate processes, etc.

So, while we might borrow ideas or even (license permitting) code from existing projects, we expect to have to do some reworking. In any case, the platform question applies even if we re-use an existing daemon -- we don't want to use one that's based on a platform that might cause installation problems.

[skram → snewman]

Fair enough and good luck in the space!