[erlang-questions] The quest for the perfect programming language for massive concurrency.

Richard A. O'Keefe ok@REDACTED
Fri Jan 31 03:13:55 CET 2014


On 31/01/2014, at 5:19 AM, kraythe . wrote:
> In a relevant language, create an array of 1000 numbers. Initialize all of the values in the array to zero. Create two threads that run concurrently and which increment each element of the array one time.

Does that mean something like

	a := (1 to: 1000) collect: [:each | 0].
	b := [1 to: a size do: [:i | a at: i atomicUpdate: [:x | x + 1]].
	b fork.
	b fork.

(Bog standard Smalltalk except for #at:atomicUpdate:, which is
exclusive to my Smalltalk implementation, but would fit easily enough
into others and was trivial to implement.)

The Scala version is, well, it makes me even fonder of Smalltalk...

The thing is that this exercise is a very imperative one. 
> 
> Scala: 
> Pros: 
> 	• Based on Java Ecosystem so easier to staff because good Java devs can convert to Scala.

Scala is different enough from Java that I think anyone who can
adapt to Scala can adapt to Erlang about as easily.  Data would
be nice of course.

> 	• Decent tools (which are getting better). Many libraries. 
> 	• Static typing with type inference.

Erlang has the Dialyzer.

I often think that if you *need* powerful modern tools to work
with a language, your language is doing something wrong.

> 	• Fewer general purpose libraries and no major central repositories. I don't want to write code to create JSON, that isnt part of my business scope. I will pick that one of the shelf If i can.

There are plenty of JSON libraries; your only problem is choosing
the shelf to pick one off.

> 	• Records as the only structured data type is ... annoying.

You may have missed the announcement of maps.




More information about the erlang-questions mailing list