[infinispan-dev] scala code in Infinispan

Bela Ban bban at redhat.com
Thu Jan 31 09:19:34 EST 2013


On 1/31/13 2:17 PM, Manik Surtani wrote:
> On 31 Jan 2013, at 13:14, Bela Ban <bban at redhat.com> wrote:
>
>>
>> On 1/31/13 1:48 PM, Mircea Markus wrote:
>>> Agreed on all points.
>>> OTOH learning/using a new language can be good fun, so with that in
>>> mind having Scala in ISPN might be a positive think. From what I saw
>>> discussing with people is that not everyone shares this enthusiasm in
>>> using Scala, and even fewer in debugging Scala.
>> Agreed.
>>
>> *If* someone wants to learn a new *great* language, learn Clojure. Blows
>> Scala right out of the water**1 :-)
> I've heard some interesting arguments about how Clojure won't scale due to its concurrency model (everything's immutable, defensive copies everywhere), meaning that CPU caches end up being useless.  :)  I don't know enough about how it is implemented to comment myself though.

Those comments apply to functional languages in general, Scala included.

Immutability is a 'feature' of functional languages in general; and the 
main reason IMO why they never caught on. At least, Clojure is not as 
pure as scheme and does allow operations that have side effects 
(refs/vars), e.g. change a data structure, so you can choose in some 
scenarios to trade purity for efficiency.

Now that we have more memory, the CPUs have become faster, GC is better, 
and data structures (e.g. in Clojure) have more efficient 'copying', the 
severity of the problem has been somewhat reduced, but it is still 
there. Clojure for example, has pretty efficient copying of maps or 
lists, where they actually don't really copy stuff, but still reference 
the same data until a a real copy is required. Quite similar to 
copy-on-demand structures, or even to the read-committed / rep-read 
implementations in Infinispan.

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)



More information about the infinispan-dev mailing list