Pinderkent

We're beginning to enter a new era in computing. We're rapidly leaving the days of uniprocessor systems. This has been the trend in the enterprise world for some time now. But with Intel and AMD releasing dual- and quad-core CPUs, and these CPUs being used even in low-end systems, they will soon become near-ubiquitous. Unfortunately, few of our programming languages and development platforms are truly equipped to handle the parallelism that we will be seeing on the typical desktop system in the near future.

It has been suggested that there won't be a "next big language". This may be the case. However, I suspect that there may be a "next big language", and I would not be surprised if it were Erlang, or a language very similar to Erlang.

Soon enough people will come to realize that languages like Ruby and JavaScript just can't scale on the massively-multicore systems we will likely find in nearly everyone's desktop or laptop system. Yes, multithreaded programming with Ruby is possible, just as it is with C, C++, Java, and many other languages. But in such cases, it was tacked on as an afterthought, without any real integration with the core of the language. Erlang was designed from the ground-up to take into account concurrency and distributed systems. Thus it is very natural and easy to write highly-scalable software systems using Erlang, whereas it becomes much more of a challenge in existing languages.

I don't believe that Ruby nor JavaScript can be retrofitted to adequately support parallelism needed to effectively use the multicore systems of the near future. Aside from the reasons above, we also can't forget that they're straight from the world of imperative programming. Maintaining and manipulating state is paramount. And that just doesn't fly in the world of highly-threaded programs. So if Erlang (or a language similar in nature to it) isn't the main language of the future, perhaps it will be a purely functional language like Haskell. With improved compiler support for automatic parallelization, it could very well allow typical programmers to write programs that essentially scale without much effort.

Maybe Ruby or JavaScript will be the languages of choice for the next couple of years. But beyond that, I don't think either will be able to keep up. As stated earlier, we're leaving the world that they're suited for, and moving to a very different landscape. It's doubtful they'll be able to catch up.

There has been a lot of discussion lately about the application development platform that Facebook has become, as well as on the various other "Web operating systems" that are being developed. For example, there was some discussion today on Slashdot about Facebook's acquisition of Parakey. I think it's quite unfortunate that the industry is heading in that direction. It's looking like that's the wrong direction to go in.

One tell-tale sign that these Web-based application platforms are a poor way to go is the very term used to describe them: "Web OS". It should be clear that they are not "operating systems" in any sense. For them to be referred to as such by their developers suggests a limited familiarity with real operating systems that interact directly with hardware, schedule processes, and manage memory and other physical resources. Such a mislabelling is quite worrying.

This comment at Reddit goes to show the pointlessness of these Web application platforms. The last sentence is particularly telling: I'm not saying that you could write a Photoshop replacement using these technologies, but it should be possible to write e-mail tools, simple games, text editors, and so on...

So these Web-based platforms aren't suitable for any significantly complex software, but they merely let us duplicate software that we already have (ie. text editors and email clients). That's not progress. It's perhaps even a regression, as no new benefits arise, but we do pay increased performance and quality penalties.

Instead of looking towards JavaScript and the Web browser, maybe the industry should be looking towards Erlang. It's clear that we've entered the era where typical desktop systems will have two or more processors. Thus the software we develop will need to take parallelism into account. Erlang can handle this with ease, in a very natural fashion.

What I imagine will happen is that these Web application platforms will gain popularity, even in the face of poor scalability on multicore desktop systems. So in a few years there will probably be efforts to molest and twist the existing browsers into having better support for parallel processing. Perhaps by that point it will be realized that the Web browser is a poor platform for software development. It's too bad it will probably take several years before the industry in general realizes that they should've just started looking into Erlang-based solutions earlier.