I looked at node.js for a system I'm involved with creating, but ultimately we went with Erlang just because it's been around a lot longer and is more stable in terms of things like this. We're working on a semi-embedded system that will not always be on-line or accessible for debugging. We also considered Go, which probably would have been more familiar to C++ guys, but it was also deemed a bit immature even if it seems like a very pleasant language to work with.
Of the three options you've considered, Erlang is clearly the best choice, but why haven't you even considered Java (or any other JVM language)? When it comes to monitoring, profiling or debugging a long-running application, nothing comes close to the JVM. And, needless to mention, it's extremely mature and stable.
A Java memory leak can be solved in a matter of minutes, or – if it's especially complex – in a couple of hours tops. You can take a heap dump and analyze it with Eclipse Memory Analyzer, and if you need allocation stack-traces, you instrument your code with VisualVM. All of this can be done remotely and without stopping the app.
Flight Recorder, which has recently been added to the HostSpot VM, even gives you instrumentation with hardly any performance penalty (though it requires a commercial license if used in production).
Java lets you trade memory for performance. The bigger the heap, the less frequent the young-gen GCs, and the less frequent young-gen GCs, the less garbage you need to collect (because more young objects get to die). So most times when you see large Java heaps that's by choice, as many people prefer paying with memory (which is cheap on servers) for performance. So Java is a "memory hog" only when you want it to run at full speed (and that's true for all generational GC environments). But nothing is stopping you from running "standard" Java with a really small heap; you'd still get better performance than Node or Erlang, and get enjoy all of the excellent tools.
Not knowing it well is a good reason not to use it, though.
I know for a similar project I did, I ruled out Java as I (and my team at the time) were not very productive in it. It mattered, in that instance, but might not in some others. Depends on your teams skill set I guess!
I've seen two sources of memory leaks in Erlang based systems: 1) unbounded process message queues, and 2) passing binaries across process (pid) boundaries.
Many beginning erlangers run into these, and they're relatively easy to identify and correct. With a little practice, these become easy patterns to recognize and avoid.
As far as httpc, I'm unaware of that bug -- but I can say that I recently worked on a commercial product that leveraged httpc as a core component of the service, and it worked fine.
> As far as httpc, I'm unaware of that bug -- but I can say that I recently worked on a commercial product that leveraged httpc as a core component of the service, and it worked fine.
Cool writeup though!