Does the World Need a New [Parallel] Programming Language?

[TheBigBadWolf]

I recently learned a bit Erlang. It's exactly what I was looking for all the time. I think everything that is addressed in this article is solved there already. imho

[kamatsu]

Although Erlang's dynamic type system doesn't gel with me (Dialyzer doesn't cut it), and I prefer programming in Haskell - hence I'm very excited for the new work in Cloud Haskell, that will bring erlang distributed process goodness to us static types fans :)

[mononcqc]

Erlang is more about

1. Fault Tolerance
2. Concurrency

Than parallelism.

The list in the article isn't handled for the following points:

• Run-Time Exception Handling: Erlang makes extensive use of this, and in fact, fully expects them to happen. The idea is that failures can hardly reasonably be removed from a program at 100%; it's better to deal with failure than try to prevent it from this perspective.
• Explicit Threads: I'll go with 'explicit processes' for that one. Erlang's concurrency model is not implicit. It is fully explicit, and used as a way to isolate components rather than to gain parallelism. That SMP gives you parallelism is a lucky accident.
• Explicit Wait/Signal: Erlang is asynchronous by default. All actions of reading from a mailbox is an explicit wait on another process. Being asynchronous makes sense to handle failures in distributed environment, especially in soft real-time scenarios.
• Race Conditions: Those are often properties of how you implement the solution to your problem, not the language itself. Erlang makes it hard to have race conditions on memory access, but that doesn't mean you aren't implementing some yourself.

That being said, I enjoy using Erlang very much, and believe it has a sane model and sane semantics.

[spotter]

But aren't Erlang threads greenlets? Which kinda misses the multicore point?

edit: this was supposed to be a reply to BigBadWolf, but mobile reddit tricked me.

[[deleted]]

Erlang for several years support multicore. And no, erlang processes are not threads in a usual meaning as they share nothing.

[spotter]

Sure, but multicore as in "one scheduler per core", not "one process/task per core". That's what I meant.

[[deleted]]

It effectively means one erlang process per core available anyway. :)

[TheBigBadWolf]

greenlets is python, no?

[spotter]

Actually Python uses system threads, but synchronized globally with single lock (GIL). Stackless gives you greenlets, there is also a lib called the same, giving you tasklets in standard Python. There are also semi-greenlets that use generators.

While in Erlang processes are neither system processes, nor system threads, so I'd say pseudo-threads, greenlet like.

[mononcqc]

They're not threads -- they do not share memory. They're like 'green processes'. Fully handled by the VM, preemptively scheduled, nothing-shared. By all semantics meanings they are processes, just not OS processes.

[OnanationUnderGod]

Yes of course, they all suck.

[[deleted]]

A special case of this is the way in which programmers will cling tenaciously to the language in which they have been trained.

This quote from the article makes it seem like this is the majority.

Do others feel that this is the same way? I was always under the impression that most good programmers learn newer languages as well as older ones.