

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):<p>* 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.<p>* Good basic libraries for filesystem and network access, including HTTP+SSL.<p>* Stable -- can expect to run for months at a time without hiccups or memory leaks.<p>* 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.<p>* 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.)<p>* Portable to Windows and OS/X without undue difficulty.<p>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
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
Fair enough and good luck in the space!

