Clearly Time To End This

May 18th, 2008  |  Published in commentary, distributed systems, erlang, reliability  |  6 Comments  |  Bookmark on

A technical discussion stops being a vehicle for learning when the following start to occur:

  • Someone starts making stuff up.
  • Instead of answering questions put to them, someone starts pointing out “flaws” in the questions themselves.
  • One challenges the other to some sort of programming contest.
  • Name calling.

The first two aren’t so bad, but when either of the latter two appears, it’s time to stop. Unfortunately, the third item has now entered my back-and-forth with Ted Neward. Since Ted has given me the last word, I’ll take it, but it’s clearly time to move on.

Given that a number of statements Ted’s made about Erlang in this discussion simply aren’t true, it’s quite clear Ted has never written any production Erlang code. [Update: Patrick Logan has posted a detailed analysis of Ted’s misunderstandings of Erlang.] Being a long-time author, it bothers me when people write authoritatively on topics they have no business writing about, so my only goal with my responses in this conversation has simply been to set the record straight with respect to Erlang. Ted originally said Erlang was a study in concurrency; I merely pointed out that it was more importantly a study in reliability. That’s really not even debatable. Unfortunately, it’s turned into a frustrating one-sided conversation because Ted lacks any detailed knowledge of Erlang, so he keeps unhelpfully trying to shift the focus elsewhere.

In his past two responses, Ted has picked at my questions like a grammar school English teacher, accusing me of conflating things, making bad assumptions, etc. I see that Patrick Logan is trying to clarify things, which might help. Yet Ted still hasn’t adequately explained why he’s taken such a hard stance against reliability being a fundamental feature of Erlang, nor how UNIX processes and Erlang processes are the same, as he keeps asserting, nor has he explained why he thinks it’s much, much harder to make an Erlang application manageable and monitorable than it is to build Erlang’s reliability into other systems like the JVM or Scala.

But now, we see the worst: the “programmer challenge.” Ugh. Thankfully, I’m sure most readers know that a programming contest of the sort Ted proposes would prove absolutely nothing. I guess he proposed it because I mentioned how I recently spent a quarter of a day making an Erlang application monitorable, in response to his continued claims that doing so is really hard, so now he wants to make a competition of it. I’d rather that you just explain, Ted, the experiences you’ve had that have led you to claim that Erlang applications can’t be easily managed or monitored. Better yet, since you’re the one who wants a contest, and given that you’re the one making all the claims, why don’t you go off and see how quickly you can build Erlang’s reliability into Scala and the JVM, since you claim it’s so simple?

If you’re a regular reader of Ted’s blog, you know that Ted generally offers good advice and you can learn useful things from him. He’s a good writer and a wonderful conference presenter, as he can make hard concepts easier to grok and generally does so with humor to keep you awake. But I feel that anyone in Ted’s position has a responsibility to avoid passing off incorrect information to his readers as fact. My advice therefore is simply that you don’t take what Ted says as gospel for this particular topic. Let me assure you that Erlang offers far, far more value than just exceptional concurrency support, which is where Ted’s initial posting in this thread seemed to want to limit it, and which is all I objected to. Unlike Ted, I’ve written quite a bit of Erlang code, and I use it every single day. If you write distributed systems, you owe it to yourself to explore Erlang’s capabilities and features. I’ve been writing and researching middleware and distributed systems for nearly 20 years now, and I’ve seen a lot over the years. Erlang is by far the most innovative and sound approach to distributed systems development I’ve ever seen and experienced — the trade-offs its designers chose are simply excellent. Like I’ve said numerous times over the past year, I really wish I’d found Erlang a decade ago, because I know for certain it would have saved my teams and me countless hours of development time.


  1. René Ghosh says:

    May 19th, 2008 at 4:38 am (#)

    I commend your maturity and serenity in refusing to let discussions and arguments degrade into conflicts. The internet definitely needs more bloggers such as yourself.

  2. Ola Bini says:

    May 19th, 2008 at 4:56 am (#)

    This has been an amusing back-and-forth, but I do believe it’s for the best that it stops now. In general I am in favor of your arguments, but Ted has got a good point that having Erlang’s reliability guarantees builtin in a general purpose VM like the JVM or CLR would be highly useful.

    Interesting sidenote. Both you and Ted seems to fall into the fallacy of Appeal to Authority – where the authority is yourself – quite often. Just note your last paragraph.

  3. steve says:

    May 19th, 2008 at 9:32 am (#)

    @René: thank you.

    @Ola: I’d say it’s less an appeal to authority than it is an appeal to practicality, reality, and experience. At the end of the day, all I can relate to you are my own experiences. It’s the same thing that makes your own blogging so valuable to the rest of us.

  4. Mike Wilson says:

    May 21st, 2008 at 2:57 pm (#)

    Having spent decades up to my neck in c++ socket code (something I quite enjoy actually) I’ve got to say the one thing this all has done for me is to make me look about for some, any excuse to start noodling around with erlang.

  5. Bill Burke says:

    May 28th, 2008 at 8:57 am (#)

    Steve, I thought you were behind the UBER-VM? If we’re gonna have this polyglot world, we’ll need to unify under something like the VM or integration is gonna be a bitch.

  6. steve says:

    May 29th, 2008 at 4:05 am (#)

    @Bill: yes, an uber-VM would be nice for a lot of applications. All I’m saying, though, is that when Ted or anyone else says “oh, we’ll just build Erlang’s reliability into this VM over here,” I think they’re dreaming, unless they’re aware that it’ll take years to get there but they’re leaving that part out for whatever reason.