Very much so. We've been doing parallel programming since 1986 and now we have real parallel hardware to run our programs on, so our theories are turning into reality. We know how to write parallel programs, we know how to deploy them on multicores. We know how to debug our parallel programs. We have a head start here.
What we don't know is the best way to get optimal performance from a multicore so we're doing a lot of tweaking behind the scenes.
The good news for the Erlang programmer is that they can more or less ignore most of the problems of multicore programming. They just write Erlang code and the Erlang run-time system will try and spread the execution over the available cores in an optimal manner.
As each new version of Erlang is released we hope to improve the mapping onto multicores. This is all highly dynamic, we don't know what multicore architectures will win in the future. Are we going to see small numbers of complex cores or large numbers of simple cores with a "network on chip" architecture (as in the Tilera chips, or the Intel Polaris chip). We just don't know.
But whatever happens Erlang will be there adapting to the latest chipsets.
Did you see this trend coming in the early days of its development?
No. We always said "one day everything will be parallel" - but the multi-core stuff sneaked up when we weren't watching. I guess the hardware guys knew about this in advance but the speed with which the change came was a bit of a surprise. Suddenly my laptop had a dual-core and a quad-core appeared on my desktop.
And wow - when the dual core came some of my Erlang program just went twice as fast with no changes. Other programs didn't go twice as fast. So the reasons why the program didn't go twice as fast suddenly became a really interesting problem.
What are the advantages of hot swapping?
You're joking. In my world we want to build systems that are started once and thereafter never stop. They evolve with time. Stopping a system to upgrade the code is an admission of failure.
Erlang takes care of a lot of the the nitty-gritty details needed to hot-swap code in an application. It doesn't entirely solve the problem, since you have to be pretty careful if you change code as you run it, but the in-build mechanisms in Erlang make this a tractable problem.
Functional versus Imperative? What can you tell us?
It's the next step in programming. Functional programs to a large extent behave like the maths we learned in school.
Functional programming is good in the sense that it eliminates whole classes of errors that can occur in imperative programs. In pure functional programs there is no mutable data and side effects are prohibited. Since you can't mutate data you don't need locks to lock the data while it is being mutated, since there is no mutation. This enables concurrency, all the arguments to any function can be evaluated in parallel if needed.
Interpreted versus compiled? Why those options?
I think the distinction is artificial. Erlang is compiled to abstract machine code, which is then interpreted. The abstract machine code can be native code compiled if necessary. This is just same philosophy as used in the JVM and .Net.
Whether or not to interpret or compile the code is a pure engineering question. It depends upon the performance, memory-size, portability etc. requirements we have. As far as the user is concerned their is no difference. Sometimes compiled code is faster than interpreted code, other times it is slower.
Looking back, is there anything you would change in the language's development?
Removing stuff turns out to be painfully difficult. It's really easy to add features to a language, but almost impossibly difficult to remove things. In the early days we would happily add things to the language and remove them if they were a bad idea. Now removing things is almost impossible.
The main problem here is testing, we have systems with literally millions of lines of code and testing them takes a long time, so we can only make backwards compatible changes.
Some things we added to the language were with hindsight not so brilliant. I'd happily remove macros, include files, and the way we handle records. I'd also add mechanism to allow the language itself to evolve.
We have mechanisms that allow the application software to evolve, but not the language and libraries itself. We need mechanisms for revision control as part of the language itself. But I don't know how to do this. I've been thinking about this for a long time.
Instead of having external revision control systems like Git or Subversion I'd like to see revision control and re-factoring built into the language itself with fine-grain mechanism for introspection and version control.
Will computer science students finally have to learn about dining philosophers?!
Easy - give 'em more forks.
Finally, where do you envisage Erlang's future lying?
I don't know. Erlang destiny seems to be to influence the design of future programming languages. Several new programming language have adopted the Erlang way of thinking about concurrency, but they haven't followed up on fault-tolerance and dynamic code-change mechanisms.
As we move into cloud computing and massively multicores life becomes interesting. How do we program large assemblies of parallel processes? Nobody really knows. Exactly what is a cloud? Again nobody knows.
I think as systems evolve Erlang will be there someplace as we figure out how to program massively fault tolerant systems.