Sorry to be vague on size. I mostly meant number of machines / number of cores. Certainly the sizes of Erlang software systems is sizable.

As far as SMP goes, I’m looking at the high core count machines, and pretty much everybody is on the same footing there, simply because the hardware is pretty recent.

When you say that most Erlang-based applications you’ve heard of are small, on what dimension do you measure? Number of cores? Number of computers? Number of concurrent processes? LOC?

In terms of LOC, there are several commercial systems built in Erlang with hundreds of thousand lines of code. The biggest I know of is closer to 2 million. It’s not uncommon for these systems to have tens of thousand concurrent processes on each node. These systems were not described at the Erlang Factory, since they are more or less ‘legacy’ in the Erlang community.

In terms of number of cores, I know of prototype systems using 24 cores, but this is largely uncharted territory. The long-running telecom systems are mainly using quad-cores AFAIK. They tend to lag behind, since they need to wait for NEBS-compliant versions of the processor boards.

Since you mention Facebook chat, I’m tempted to think that you mean ‘big’ in terms of number of computers. Otherwise, in terms of functional content, the Kreditor system mentioned at the Factory is far more complex.

Commercial, high-availability products have been using SMP Erlang in the field since 2007. Granted, this is not a terribly long time, but I think there are certainly enough commercial users out there to label SMP Erlang as battle tested.

Travis,
Keep in mind that most cloud environments are provisioned via some form of virtualization. That’s likely to impact any numbers that you might generate there.

Ronen,
Global interpreter locks.

Nicolas,
Yep, CTM style dataflow concurrency is definitely underrated.

Mac,
Yes, I’ve seen the talk and several earlier variants, and have talked to Rich in person.

Leo,
If you are happy using multiprocessing, that’s great. It doesn’t really help raise the level of concurrent programming, it’s just an implementation detail for getting parallelism.

Less nuance seems ok to me in places…

“Experiments being run on 2 thread MacBook Pro’s are probably not good indicators of what happens at even 8 threads.”

I sort-of wonder why you feel the need for the “probably”?

I have not yet found an application in my current problem domains of choice (dynamic websites and analytics processing) where dual-core helps predict the performance of many-core.

But then some things deserve more nuance…

“This makes it hard for me to take certain kinds of systems seriously, like concurrency solutions running on language implementations with Global Interpreter Locks.”

Hmm. I’ve found the multiprocessing module rather easy to use and I’ve found the resulting process/threads hybrids (a bit over one process per CPU core seems to work well) sometimes work better in practice than single-process multi-hardware-thread things on the JVM. I’d argue you should take seriously any setup that solves real-world problems with decent real-world performance

http://www.infoq.com/presentations/Value-Identity-State-Rich-Hickey

Nice overview, by the way. I’ve been working with dataflow variable based systems in several languages lately, and it’s definitely a useful abstraction, even though it doesn’t get as much (enough?) press as actor or STM based systems.

The point is, you have to run on actual hardware to have believable numbers.

So what’s a poor developer to do?

If you’ll indulge me for a moment, I think it would be real neat if I could sign up with a cloud computing service and fire up a 256 thread machine for a few hours to play with some of these concurrency paradigms in the Real World.

A million tiny Wide Finders. Exciting!

http://www.barrelfish.org

The Multikernel: A new OS architecture for scalable multicore systems. In Proceedings of the 22nd ACM Symposium on OS Principles, Big Sky, MT, USA, October 2009
http://www.barrelfish.org/barrelfish_sosp09.pdf

Reid