What can I only do in Erlang?

I read that first answer (and the others) carefully before writing the above, and I don't think it does. Well, let me be more precise.

The answer addresses the question I think the questioner intended to ask. What the answer does not do is fully disambiguate the question as asked, nor does it even point out that the question as asked is ambiguous. It just takes what it thinks is the most obvious interpretation, and answers that.

Which is fair enough. Most people are going to adopt that interpretation and understand the intent of the question. That's not addressing the point I'm trying to make, which is that the question as asked is ambiguous, and yet a simple re-wording would not be ambiguous. Or at least, not as ambiguous.

But I guess my point is lost, and people will down-vote this thinking I'm just picking nits. Lost cause, but I honestly don't understand why programmers of all people should care so little about the careful and precise use of natural language.

They appear not to, and I'll have to take that as an axiom without understanding.

To be honest, your reply has made me stop completely and reassess everything. In particular, the fact that you of all people seem not have missed completely my intended point makes it perfectly clear to me that I quite simply have failed utterly to make my point at all. I know your posts and comments on HN, I recognize your nick, so to have you not see the point means that, somehow, it's simply not there to be seen. I'll have to go away and think again as to whether it is in fact possible to make the point, and if possible, whether I'm a good enough writer to do so. Current evidence suggests not.

And finally, you say ...

    That's actually the first thing the
    answer in the post addresses ...

Maybe I've mis-interpreted your use of "that's", and perhaps I don't know which part of what I've written you think is being addressed in that first answer. Perhaps we're just talking past each other.

You're probably thinking about it the wrong way then. It turns out that even in cases where you don't have some massively distributed, scalable needs, there are a lot of cases to use Erlang. While it makes insanely difficult problems tractable, it can also make moderately challenging problems simple (and it sometimes can make simple tasks irritating; see usual list of Erlang complaints).

Just about any sort of web backend (that isn't having to do a whole lot of number crunching), any sort of interaction with hardware, handling/transport of binary data (as mentioned above), and of course any time you need reliability, it's worth considering.

But even in areas where there's not an obvious win, a lot of problems that are traditionally done in a single threaded manner can be made simpler in a concurrent language like Erlang.

An example I like to give is time based task scheduling. In a traditional language, you'd implement something like that with a priority queue. Which is fine, but you have a lot of work. First, what happens if timings change? You have to rejigger -everything-. What happens if you have multiple tasks at the same time? You need a threadpool or similar to dispatch these things onto. What happens if one task itself creates a new task for a later time? You'll have multiple people adding things onto the priority queue, so now you need to start locking. And of course, since you've got your dispatching process sleeping until the next task is to start, you have to make sure any time you modify the queue, you remember to notify that sleeping task, so it can update as necessary. There is a lot to get wrong.

In Erlang? You spin up a separate process for each task, with a timer. Done (with caveats; you likely will need to persist the task information and load it periodically into a task+timer process, but that's pretty trivial).

A similar case can be made for functional compared to a more procedural approach. That's a little too long winded for here, but even examples that seem -ideal- for OO, can oftentimes be described more simply in a functional, data-centric manner, and future refactorings are made simpler as well in doing so.

  > I didn't downvote you, of course, since
  > people can't downvote stuff on articles
  > they have posted.

I knew that, but thanks for mentioning in.

  >> Perhaps we're just talking past each other.

  > Probably. I think most of us saw the title
  > and reacted like the guy posting "well,
  > technically, nothing" and moved on to the
  > however, which is a fairly straightforward
  > list of "what are the things this system is
  > the best at", which is mostly what we're
  > interested in as programmers and/or startup
  > people.

Indeed, and I agree entirely with that. It still completely ignores the point I was trying to make, though, hence my confusion. So to elaborate minimally:

The question as asked is ambiguous. People are putting a reasonable interpretation on it and answering that interpretation, and that's fair enough. I'm trying to point out that more precise use of language costs little, and creates significant benefits in more effective communication.

Seems it's a lost cause, even among programmers, for whom ultra-precise communication is part of their work.

'Nobody ' is not quite correct. What you probably mean is not everyone needs reliable messaging.

As a former TIBCO and MQ developer, I could not have done without them when developing trading applications.

Down vote = I don't agree with your statement normally here. Not that it might be a starting point on a conversation?