2

So I watched this video from a number of years ago (2008), where Joe Armstrong explains the background of Erlang. video link He makes quite a case, and the piece I am asking about is when he says this at 13:07:

[Erlang is a] concurrent language; by that I mean that processes in the language are part of the programming language. They do not belong to the operating system. That is really what is wrong with languages like Java and C++ is that the threads are not in the programming language; the threads are something that is in the operating system and they inherit all of the problems that they have in the OS. One of the problems is the granularity of the memory management system...

And he goes on about the issues with thread management and how that relates to this disconnect between the language and the OS. And THEN goes on to say that Erlang is uniquely positioned to leverage multi-core technology for that reason, namely that it can manage cores 'directly' without using threads at all? Or did either understand him wrong, or perhaps one or more new languages has arisen in the last 8 years to challenge Erlang in this arena?

Thanks very much for any references or comments that might shed light on this matter.

kristeraxel
  • 39
  • 9
  • Haven't seen the part you conclude from, but he probably means an Erlang program can utilize multi-core systems very well, without asking *programmer* to use threads; there is no thread visible to programmer. Erlang itself should use threads for making best use of cores. – reith Dec 14 '16 at 06:43

1 Answers1

1

Erlang VM spawns OS threads (one per CPU core in default) and they run process schedulers. (VM also can spawn more threads for IO operations, drivers and in NIFs but they don't run Erlang code.) Schedulers schedule execution of code in Erlang processes. Each Erlang processes are (can be and should) very lightweight compared to OS processes and OS threads and are completely separated from each other. It allows a unique design of applications with easy, safety, robustness, and elegance utilizing multicore HW. For more information about the mapping Erlang processes to cores see my answer to other question. For a detailed explanation how scheduling work in detail see Erlang Scheduler Details and Why It Matters blog.

Community
  • 1
  • 1
Hynek -Pichi- Vychodil
  • 26,174
  • 5
  • 52
  • 73
  • can you speak to the differences with other languages like Scala, Go, Closure - you say the __VM spawns OS threads (one per CPU core in default)__ is this similar to how cores are handled in Scala, Go, or Closure? – kristeraxel Jan 03 '17 at 09:50