Erlang vs node.js

I've written about Erlang in the past, and my suspicion that, soon or later, other languages/systems will come along and "eat its lunch".  Scala is one such potential contender.  Another that has been gaining some visiblity lately is node.js, a simple framework for creating networked applications on top of Google's V8 Javascript engine.

I should define what Erlang's lunch is a little bit better before we go on.  Erlang does several things really, really well; better than many existing, mainstream systems:

  1. Concurrency – the Actor model that it uses is much easier and more pleasant than dealing with threads.
  2. Distributed systems – Erlang makes this fairly easy and pleasant as well.
  3. Fault tolerant systems – using its distributed powers, Erlang is good for writing things like telephone switches that can't spend any significant time down.

Of these, I think the big one is concurrency.  Distributed systems are nice, but not a critical point for most people.  Same goes with fault-tollerant: those who need it really need it, but the rest of us are willing to make some compromises.  Our web applications are important, but generally not something where people's lives hang in the balance.

How does Erlang do "concurrency"?  The developer creates Erlang "processes" that interact with one another by passing messages.  These are not real, OS level processes, though, and this is critical to how Erlang operates.  Since these processes must all coexist within one real, system level process, it is absolutely essential that no operation that they perform hangs the entire system!  The Erlang runtime system is built around this concept.  Any Erlang process can do things like read and write to the disk or network, or have a "while (true) { …. }" loop (it doesn't actually look quite like that in Erlang, but that's the idea), and it won't wedge the system.  This knowledge is also critical when you want to interface Erlang to the outside world: if your C library contains a routine that might block for a long time, you can't just call it from Erlang as it won't be a well-behaved part of Erlang's world (there are ways around this of course, but make life a bit more complicated for the developer).  All this is done with Erlang's scheduler: each Erlang process gets a number of operations it can run before some other process gets to run, so even our while loop will only run for a bit before the system moves on to something else.   IO is rigorously done with non-blocking calls internally in order to keep that from becoming an issue.

No other system that I know of has such a focus on being non-blocking, and node.js is no exception: a while(true) loop is perfectly capable of wedging the system.  Node.js works by passing functions (closures, in many cases) around so that work can be performed as needs be.  However, the actual functions that run actually do block the system, and thus must be written in order to not run for too long.  Also, and this is important, Node.js also does its best to make IO non-blocking by default, so that you don't have to worry about IO calls.

Node.js isn't up to the level Erlang is at, because it requires more manual intervention and thinking about how to do things, but it's probably "good enough" for many tasks.  How often do you really write code with so many calculations that it slows things down?  Not often in my case – the real world problem I most often encounter is IO, and node.js does its best to make that non-blocking, so that it can be handled in the "background" or a bit at a time, without wedging the system.  And if you really needed to write a long-running calculation (say you want to stream the digits of PI or something), you can break up your calculation manually, which may not be quite as elegant as Erlang, but is "good enough" for many people.

"Good enough" concurrency, combined with a language that is at least an order of magnitude more popular than Erlang, and a fast runtime, combined with ease of use in general (it's way easier to get started with node.js than with most Erlang web stuff) make for a system that's likely to do fairly well in terms of diffusion and popularity, and is going to "eat some of Erlang's lunch".  Or perhaps, rather than actually taking users away from Erlang, it's likely to attract people that might have otherwise gone to Erlang.

Make Life Easier for European Startups: Simpler/Cheaper Limited Liability Companies

As I've mentioned here before, one of the differences between "Europe" and the US is just how cheap it is to start a company in the US.  Before we go any further, I'll take a moment to add the standard "yes, I know that Europe is not one country" disclaimer, and specify that I'm mostly talking about continental Europe.  Starting a company in the UK or Ireland isn't nearly as bad.

In Oregon, I spent $55 to create DedaSys LLC.  If I'd created it with one or more partners, I would have spent something on a lawyer in order to create a solid agreement, but that is of course a voluntary expenditure that we would pay for because it provided us with some value.  In Italy, it costs thousands of Euros just to get started with a company; before you've made any money at all.  And, while there are gradual improvements, it's still a bureaucratic process that pretty much must involve at least an accountant and a notary public.  And you have to involve the very arbitrary number of 10,000 euros of capital in the company, supposedly there as a guarantee for the people you're doing business with.  But 10,000 is not nearly enough to cover some kinds of problems you might cause, and way more than, say, a web startup with a couple of guys and their laptops need.  My friend Salvatore says it's possible to sort of "get around" sinking the full 10K into your company, but in any case, the principal of "caveat emptor" is a more sensible one.  At most, make a transparency requirement so that people dealing with companies can tell exactly how much reserves they have.

During a recent bout of cold/flu, compliments of our daughter's nursery school, when I had some extra time on my hands, I decided to do something about this, however much it may be pissing into the wind.  I set up a site:

http://www.srlfacile.org (warning: Italian only)

As well as a Google Group, and petition for people to sign, in an attempt to make a little bit of noise about the problem, here in Italy.

While it's likely that the actual bureaucratic mechanisms are more smoothly oiled in other European countries, I have my doubts as to whether the actual amount of paperwork can compete with the very minimal page or two required by many US states.  And in any case, the costs are still quite high, and while we all have different levels on the idea of the role of government, and ideal levels of taxation, I think we can agree that it's sensible to levy taxes only after a company has begun to make money!

So – how about it?  Anyone want to create sister initiatives in other countries in Europe where things aren't as simple and easy as they should be?  Anyone care to tell of how this problem has been fixed elsewhere?  I've heard tell that in Germany, there is now a simpler/cheaper way to create limited liability companies.

US Exports: “The Cloud”?

An Economist special report in last week's print edition talks about how the US will need focus more on savings and exports:

A special report on America's economy: Time to rebalance

I've been thinking about that for a while too, especially after the dollar's recent weakness, although it has been strengthening some, lately, apparently due to the state of Greece's finances…

I think that the computing industry is, in general, well poised to take advantage of that.  For instance, what could be easier to export than computing power or "Software as a Service"?  All it takes is a few minutes for someone in Europe to sign up to a US-based service with a credit card.

For instance, compare Linode's prices and good service with most of their European competitors (gandi.net for instance, who are good people, and you have to love that they put "no bullshit" right on their front page).  Not that they don't have good service in Europe, but it's very difficult to compete on price with the dollar being significantly cheaper.  With the dollar where it is right now, gandi is almost, but not quite, competitive with Linode.  If you don't include taxes.  If the dollar weakens again, though, things could easily tilt far in Linode's favor.

Besides a weak dollar, I think it will be important for companies in a position to do so in the US to focus on "the rest of the world".  The US is a big, populous country where it's very easy to forget about far-off lands.  Compare my home town of Eugene, Oregon to where I live in Padova.  Google Maps says that it takes 7+ hours to drive to Vancouver, Canada (which, to tell the truth, isn't all that foreign in that they speak English with an accent much closer to mine than say, Alabama or Maine).  Going south, Google says it's 15+ hours just to San Diego, although I think that's optimistic myself, given traffic in California.  From Padova, I can be in France in 5 hours, according to Google, 3 hours to Switzerland, 4 to Innsbruck, in Austria, less than 3 hours to the capital of Slovenia, Ljubljana, and around 3 hours to Croatia, too.  And if you wanted to throw in another country, the Republic of San Marino is also less than 3 hours away, according to Google's driving time estimates.   You could probably live your entire life in a place like Eugene and never really deal much with foreigners, whereas here, nearby borders are both a historic and an ever-present fact.

The outcome of this is that, to some degree, people in the US have traditionally focused their businesses "inwards" until they got to a certain size.  Which is, of course, a natural thing to do when you have such a big, homogenous market to deal with before you even start thinking about foreign languages, different laws, exchange rates and all the hassle those things entail.

However, if exchange rates hold steady or favor the US further, and internal spending remains weaker, it appears as if it may be sensible for companies to invest some time and energy to attract clients in "the rest of the world".

"Cloud" (anyone got a better term? this one's awfully vague, but I want to encompass both "computing power" like Linode or Amazon's EC2, as well as "software as a service") companies likely will have a much easier time of things: for many services, it's easy to just keep running things in the US for a while, and worry about having physical or legal infrastructure abroad later.  Your service might not be quite as snappy as it may be with a local server, but it'll do, if it performs a useful function.  Compare that with a more traditional business where you might have to do something like open a factory abroad, or at the very least figure out the details of how to ship physical products abroad and sell them, and do so in a way that you're somewhat insured against the large array of things that could go wrong between sending your products on their merry way, and someone buying them in Oslo, Lisbon or Prague.

Since this barrier to entry is lower, it makes more sense to climb over it earlier on.  As an example, Linode recently did a deal to provide VPS services from a London data center, to make their service more attractive to European customers. 

However, they still don't appear have marketing materials translated into various languages, and presumably they don't have support staff capable of speaking languages like Chinese, German or Russian either (well, at least not in an official capacity).  This isn't to pick on them; they may have considered those things and found them too much of an expense/distraction/hassle for the time being – they certainly know their business better than I do – and that they simply are content to make do with English.  Other businesses, however, may decide that a local touch is important to attracting clients.

What do you need to look at to make your service more attractive to people in other countries?  In no particular order:

  • Internationalization and localization.  Most computer people can "get by" in English, but perhaps their boss doing the purchasing doesn't.  If research shows that you are in a market where people value being able to obtain information in their own language, or interact with a site or service in it, make an effort to equip your code with the ability to handle languages other than English, and then pay to have your content translated.  Good, professional translations are not easy: for instance, when I translate to English from Italian (you always translate from the foreign language to your native language – anyone who doesn't isn't doing quality work) I read the Italian text, digest it, and then spit out an English version.  This doesn't mean just filling in English words for Italian, but looking at sentence length and structure, as well as translating idioms and cultural references into something that makes sense.  Basically, you read and understand the concepts and then rewrite the text, rather than simply taking each sentence and translating it.  Also, knowledge of the domain in question is important, so that you don't translate "mouse" to "topo", but leave it as "mouse" as is proper in Italian.
  • Part of internationalization is considering problems like time zones, currency, and names, which can vary a great deal from culture to culture.
  • Going a step further, you might consider hiring, or outsourcing, staff that is fluent in other languages to provide first-level support.  Reading English is one thing for many people; they can take the time to work out what one or two unfamiliar words mean.  However, if you have a problem with your server over the weekend, and you don't feel comfortable writing or calling someone to deal with a problem in English, you might consider purchasing a local service even if it's more expensive, because you can deal with people in your own language if the need should arise.  These people might either be local or remote, depending on what their role is.  For instance, Silicon Valley is 9 hours behind Central European Time, so when it's 9 AM here, and the business day is just getting started, everyone but the late-night coders in California is headed for bed, which means that it would be difficult to provide timely support unless you have someone working the late shift.  It may be easier to hire someone in Poland to support your Polish users than finding a Polish speaker in Silicon Valley who is willing to work from midnight to 9 AM.
  • Legal issues are not something I can give much advice on, but things like the privacy of people's data certainly bear considering.   If you don't actually have offices abroad, though, it's less likely that anything untoward will likely happen to you if users understand that they're using the service in question according to the laws and regulations of the jurisdiction your business resides in.  Once again though: I'm not a lawyer.
  • Even something as basic as your name needs to be carefully thought through.  "Sega" for instance, has a potentially rude meaning in Italian.  These guys are visible from a major road near Treviso: http://www.fartneongroup.com/ – doubtless the company was founded locally and subsequently grew to the point where they then learned of their unfortunate name in English (admittedly though, it does make them potentially more memorable than their competitors).

There's certainly no lack of work there, but on the other hand, it's possible to do almost all of it from wherever you happen to be located, rather than spending lots of money and time flying around to remote corners of the globe, as is still common practice in many industries.