[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