Steve Vinoski’s Blog

I see from this CIO Magazine article that Cisco is releasing a new client/server messaging system called Etch. Sigh — those who don’t know history are indeed doomed to repeat it. Some choice quotes from the article:

This week Cisco Systems announced a new messaging protocol intended to allow developers to integrate client/server applications without the overhead of traditional protocols such as SOAP.

I was unaware that SOAP had become “traditional.”

One of its design goals was to create an inter-application communications technology without SOAP’s complexity and overhead, explained Marascio. While SOAP relies on a very complicated WSDL file to define the interface between the client and server, Etch uses a file in Cisco’s own interface definition language that shares many similarities to a Java interface file.

I bet this new IDL is not only simpler than WSDL, but it probably also avoids all the impedance mismatch problems that invariably occur when mapping IDL to programming languages.

In addition to a simplified configuration, Etch also promises less overhead over the wire, compared to SOAP. In a testbed environment where SOAP was managing around 900 calls a second, Etch generated more than 50,000 messages in a one-way mode, and 15,000 transactions with a full round-trip, company officials stated.

Oh good, the “performance presumption.” So now we’re back to where we were a decade ago, at least as far as message transfer rates go. I wonder if Etch also solves the problem that the bottlenecks usually lie elsewhere?

The Etch integration into Visual Studio and Eclipse will be very familiar to anyone who has used SOAP integration tools. After authoring the IDL definition, the developer tells the IDE to generate either a client stub or a server skeleton. The client stub is usable immediately; the developer needs only to configure the transport and endpoint, and to code the message calls.

On the server, the developer takes the skeleton and implements the business logic that lives inside the message handlers.

Now that’s what I call innovation!

Projects implementing their communications using Etch aren’t out of luck if they need to interoperate with SOAP, JSON, REST or other existing protocols. Cisco has already demonstrated the capability to easily create bridges between Etch and SOAP, according to Marascio. He said that turnkey bridges to SOAP and REST should be available six to nine months after the release of Etch.

Or, to put it another way: Etch is really just adding more stuff to be developed, tested, deployed, managed, maintained, and integrated, yet it doesn’t actually solve any new problems or solve any old problems better than what already exists.

Cisco also is examining the possibility of establishing Etch as a standard. Marascio pointed out that Cisco is well represented in the IETF, the main standards body for Internet protocols. Alternatively, Cisco might attempt to promote Etch as an industry standard, an effort that would be aided by Etch’s open source nature.

Well of course you want to standardize it — where would any new NIH RPC protocol be without an accompanying standards effort? Rather than the IETF, though, perhaps you ought to get those ISO OOXML guys to rubber-stamp it?

I find it hard to believe that in 2008 people are still inventing stuff like this. Sheesh. Color me underwhelmed.

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.

Ted Neward finally responds to my comments about his remarks concerning Erlang. I really don’t mean to pick on Ted — I like Ted! — but unfortunately, this time around his response misses the mark in more ways than one.

First, Ted says:

Erlang’s reliability model–that is, the spawn-a-thousand-processes model–is not unique to Erlang. In fact, it’s been the model for Unix programs and servers, most notably the Apache web server, for decades. When building a robust system under Unix, a master-slave model, in which a master process spawns (and monitors) n number of child processes to do the actual work, offers that same kind of reliability and robustness. If one of these processes fail (due to corrupted memory access, operating system fault, or what-have-you), the process can simply die and be replaced by a new child process.

There’s really no comparison between the UNIX process model (which BTW I hold in very high regard) and Erlang’s approach to achieving high reliability. They are simply not at all the same, and there’s no way you can claim that UNIX “offers that same kind of reliability and robustness” as Erlang can. If it could, wouldn’t virtually every UNIX process be consistently yielding reliability of five nines or better?

Obviously, achieving high reliability requires at least two computers. On those systems, what part of the UNIX process model allows a process on one system to seamlessly fork child processes on another and monitor them over there? Yes, there are ways to do it, but would anyone claim they are as reliable and robust as Erlang’s approach? I sure wouldn’t. Also, UNIX pipes provide IPC for processes on the same host, but what about communicating with processes on other hosts? Yes, there are many, many ways to achieve that as well — after all, I’ve spent most of my career working on distributed computing systems, so I’m well aware of the myriad choices here — but that’s actually a problem in this case: too many choices, too many trade-offs, and far too many ways to get it wrong. Erlang can achieve high reliability in part because it solves these issues, and a whole bunch of other related issues such as live code upgrade/downgrade, extremely well.

Ted continues:

There is no reason a VM (JVM, CLR, Parrot, etc) could not do this. In fact, here’s the kicker: it would be easier for a VM environment to do this, because VM’s, by their nature, seek to abstract away the details of the underlying platform that muddy up the picture.

In your original posting, Ted, you criticized Erlang for having its own VM, yet here you say that a VM approach can yield the best solution for this problem. Aren’t you contradicting yourself?

It would be relatively simple to take an Actors-based Java application, such as that currently being built in Scala, and move it away from a threads-based model and over to a process-based model (with the JVM constuction[sic]/teardown being handled entirely by underlying infrastructure) with little to no impact on the programming model.

Would it really be “relatively simple?” Even if what you describe really were relatively simple, which I strongly doubt, there’s still no guarantee that the result would help applications get anywhere near the levels of reliability they can achieve using Erlang.

As to Steve’s comment that the Erlang interpreter isn’t monitorable, I never said that–I said that Erlang was not monitorable using current IT operations monitoring tools. The JVM and CLR both have gone to great lengths to build infrastructure hooks that make it easy to keep an eye not only on what’s going on at the process level (”Is it up? Is it down?”) but also what’s going on inside the system (”How many requests have we processed in the last hour? How many of those were successful? How many database connections have been created?” and so on). Nothing says that Erlang–or any other system–can’t do that, but it requires the Erlang developer build that infrastructure him-or-herself, which usually means it’s either not going to get done, making life harder for the IT support staff, or else it gets done to a minimalist level, making life harder for the IT support staff.

I know what you meant in your original posting, Ted, and my objection still stands. Are you saying here that all Java and .NET applications are by default network-monitoring-friendly, whereas Erlang applications are not? I seem to recall quite a bit of effort spent by various teams at my previous employer to make sure our distributed computing products, including the Java-based products and .NET-based products, played reasonably well with network monitoring systems, and I sure don’t recall any of it being automatic. Yes, it’s nice that the Java and CLR guys have made their infrastructure monitorable, but that doesn’t relieve developers of the need to put actual effort into tying their applications into the monitoring system in a way that provides useful information that makes sense. There is no magic here, and in my experience, even with all this support, it still doesn’t guarantee that monitoring support will be done to the degree that the IT support staff would like to see.

And do you honestly believe Erlang — conceived, designed, implemented, and maintained by a large well-established telecommunications company for use in highly-reliable telecommunications systems — would offer nothing in the way of tying into network monitoring systems? I guess SNMP, for example, doesn’t count anymore?

(Coincidentally, I recently had to tie some of the Erlang stuff I’m currently working on into a monitoring system which isn’t written in Erlang, and it took me maybe a quarter of a workday to integrate them. I’m absolutely certain it would have taken longer in Java.)

But here’s the part of Ted’s response that I really don’t understand:

So given that an execution engine could easily adopt the model that gives Erlang its reliability, and that using Erlang means a lot more work to get the monitorability and manageability (which is a necessary side-effect requirement of accepting that failure happens), hopefully my reasons for saying that Erlang (or Ruby’s or any other native-implemented language) is a non-starter for me becomes more clear.

Ted, first you state that an execution engine could (emphasis mine) “easily adopt the model that gives Erlang its reliability,” and then you say that it’s “a lot more work” for anyone to write an Erlang application that can be monitored and managed? Aren’t you getting those backwards? It should be obvious that in reality, writing a monitorable Erlang app is not hard at all, whereas building Erlang-level reliability into another VM would be a considerably complicated and time-consuming undertaking.

A commenter named Nick left a thoughtful response to my post about my “Multilanguage Programming” column. Rather than respond to it with another comment, I thought I’d turn my response into a full posting, as I think Nick’s feedback is representative of how many people feel about the topic.

Nick said:

I would say that instead of spending a lot of time on a conceptually different language it could be more beneficial to study, say, distributed algorithms or software/system architecture principles or your business domain. There is so much knowledge in this world that learning how to code the same thing in, roughly speaking, one more syntax seems like a waste of time. Even paying real attention to what is going on in the cloud computing can easily consume most of one’s spare time.

I think there are assumptions here that are not necessarily true. Specifically, you’re not necessarily learning how to code the same thing in multiple languages; rather, the idea is that by choosing the best language for the task, coding is “just right” for the problem at hand. For example, I know from significant first-hand experience that if you want to write a set of distributed services that support replication, failover, and fault tolerance, the code you’d write to do that in C++ will be extremely different from the code you’d write in Erlang to achieve the same thing (well, actually, you’d be able to achieve far more in Erlang, in far fewer lines of code).

This is about much more than syntax. It’s about facilities, semantics, and trade-offs. If it were just syntax, then that would imply that all languages are equal in terms of expressiveness and capability, which we already know and accept to be untrue.

The cloud computing topic actually provides a good example of why knowing multiple languages can be useful. To use the Google App Engine, for example, you need to develop your applications in Python. What if you don’t know Python? Too bad for you.

From a real life perspective, it takes years or working on nontrivial software to master a language. For example, some people still manage to have only a vague idea of util.concurent — and this is just a small enough (and well explained in the literature) part of Java. How realistic is it to expect that the majority of developers will be able to master multiple languages concurrently?

I disagree that it takes years to master a language. One of the best OO developers I ever worked with was a mechanical engineer who taught himself programming. One of my current coworkers — a relatively young guy — started programming in Erlang only a few months ago, and he’s already writing some fairly sophisticated production-quality code. In 1988, I started using C++; by 1989, I was starting to help guys like Stan Lippman, Jim Coplien, and others correct coding mistakes in their excellent books. I have a BSEE, no formal computer science training whatsoever, and am completely self-taught as far as programming languages go. (The only class I ever had in any computer language was a BASIC class I had to take in 1981.) Two other coworkers started with Python just a few months ago and they do quite well with it at this point. I can cite numerous such examples from throughout my career. I don’t think any of us are super-programmers or anything like that, so if we can do it, I don’t see why it would be a problem for anyone else.

Perhaps you’re falling trap to the “huge language” problem I mentioned in my column. It certainly can take some people many years to master enormous languages like Java and C++, but most languages are simply nowhere near that big.

And who wants to maintain a code base written in widely different languages? Which most likely means multiple IDEs, unit testing frameworks, build systems (hey, not everyone is using even Maven yet), innumerable frameworks etc. And most of the interpreted languages among those are not even likely to run in the same VM. Not to mention the number of jobs asking for non-C++/Java skills.

I use a number of languages daily and I really have no trouble maintaining the code regardless of which language any particular piece happens to be written in, or whether I wrote the code or one of my teammates did. Once you know a language, you know it; switching to it is no more difficult than using your one and only language if you’re a monolingual developer.

You also mention the “multiple IDE” problem. The first draft of my column contained some fairly direct language describing my dislike of IDEs, or more accurately, my dislike of the IDE culture, but Doug Lea suggested I take it out, so I did. The problem is that some folks let the tool drive their solutions, rather than using the tool as a means to developing solutions. I’ve had numerous people tell me they won’t consider using a language unless their IDE fully supports it with Java- or Smalltalk-like refactoring. To me, that’s completely backwards. I’d rather use an extensible editor that can handle pretty much any language, thus letting me develop optimal solutions using the right languages, rather than having a mere editing tool severely limit my choice of possible solutions.

But there are language mavens and there are tool mavens, and they typically disagree. Follow that link and read, as the posting there is incredibly insightful. I am definitely a language maven; languages are my tools. I suspect, though, that Nick and others who raise similar questions to the ones quoted here lean more toward being tool mavens. I’m not passing judgment on either; I’m only pointing out the different camps to help pinpoint sources of disagreement.

As far as unit test frameworks, build systems, and frameworks go, I haven’t ever found any big issues in those areas when using multiple languages. The reason, not surprisingly, is that knowing multiple languages gives you multiple weapons for testing and integration. Ultimately, when you’re used to using multiple languages, you’re used to these kinds of issues and thus they don’t really present any formidable barriers.

And as far as jobs go, the best developers I’ve known throughout my career have been fluent in a number of programming languages, and each of them could work virtually wherever they wanted to. I don’t believe this correlation is mere coincidence.

Curiously enough, this argumentation is hardly ever mentioned. Authors tend to assume that developers are lazy or have nothing else to learn.

I don’t assume developers are lazy. Rather, I think our industry generally has a bad habit of continually seeking homogeneity in platforms, in languages, in tools, in frameworks, etc., and we really, really ought to know better by now. Once you learn to accept the fact that heterogeneity in computing is inevitable — since nothing can do it all, right? — you find yourself able to use that heterogeneity to your advantage, rather than continually battling against it and losing.

Personally, I am planning to look at Scala and probably Erlang but even judging from the number of books on those it’s clear to me that they represent merely a niche market.

Today’s niche market is tomorrow’s mainstream market. Regardless of whether either of those languages continues to grow, learning one or both will make you a better developer than you are today.

Consider the final question I ask in my column:

After all, do any of us really believe we’ve already learned the last programming language we’ll ever need?

I suspect the vast majority of developers would answer “no” to this question. Assuming that’s the case, then if you don’t regularly practice learning new languages, how do you know when you really need to start learning a new one, and how capable will you be of learning that next language when the need arises? The longer you stay with one language, the more isolated you become, typically without even realizing it. Shifting gears gets harder and harder. Then one day you look up and all the interesting work is elsewhere, out of your reach. Is that a position you want to put yourself in?

In a recent post, Ted Neward gives a brief description of a variety of programming languages. It’s a useful post; I’ve known Ted for awhile now, and he’s quite knowledgeable about such things. Still, I have to comment on what he says about Erlang:

Erlang. Joe Armstrong’s baby was built to solve a specific set of problems at Ericsson, and from it we can learn a phenomenal amount about building massively parallel concurrent programs. The fact that it runs on its own interpreter, bad.

I might have said it like this:

Erlang. Joe Armstrong’s baby was built to solve a specific set of problems at Ericsson, and from it we can learn a phenomenal amount about building highly reliable systems that can also support massive concurrency. The fact that it runs on its own interpreter, good; otherwise, the reliability wouldn’t be there and it would be just another curious but useless concurrency-oriented language experiment.

Far too many blog posts and articles that touch on Erlang completely miss the point that reliability is an extremely important aspect of the language.

To achieve reliability, you have to accept the fact that failure will occur, Once you accept that, then other things fall into place: you need to be able to restart things quickly, and to do that, processes need to be cheap. If something fails, you don’t want it taking everything else with it, so you need to at least minimize, if not eliminate, sharing, which leads you to message passing. You also need monitoring capabilities that can detect failed processes and restart them (BTW in the same posting Ted seems to claim that Erlang has no monitoring capabilities, which baffles me).

Massive concurrency capabilities become far easier with an architecture that provides lightweight processes that share nothing, but that doesn’t mean that once you design it, the rest is just a simple matter of programming. Rather, actually implementing all this in a way that delivers what’s needed and performs more than adequately for production-quality systems is an incredibly enormous challenge, one that the Erlang development team has quite admirably met, and that’s an understatement if there ever was one.

They come for the concurrency but they stay for the reliability. Do any other “Erlang-like” languages have real, live, production systems in the field that have been running non-stop for years? (That’s not a rhetorical question; if you know of any such languages, please let me know.) Next time you see yet another posting about Erlang and concurrency, especially those of the form “Erlang-like concurrency in language X!” just ask the author: where’s the reliability?