

Clojure is One Answer - pron
http://onbeyondlambda.blogspot.com/2012/01/my-last-post-was-link-to-video-talking.html

======
moomin
As Herb Sutter recently pointed out, STM in Clojure is one answer to the
problem of programming current hardware, but future architectures may not even
have a coherent global memory model. I dare say Clojure will keep up though,
as long as the JVM does.

~~~
pron
Well, Clojure is _one_ answer. Erlang's the other :)

But actually, I heard Rich Hickey has (or had?) some ideas for incorporating
Erlang-style message passing into Clojure (at least for distributed, multi-
node programs). And Clojure is well designed for that because its persistent
data-structures are both immutable (and thus can all serve as safe messages),
and are trie-based and so require only little copying upon modification and
consequently relatively high-performance.

~~~
gtani
[http://antoniogarrote.wordpress.com/2010/09/03/jobim-an-
acto...](http://antoniogarrote.wordpress.com/2010/09/03/jobim-an-actors-
library-for-clojure/) (his more recent code for Gearman, Kilim)

Well, as other folks implementing this: haskell, F#, akka, scala actors have
shown, getting a working implementation actors is not difficult but making
sure green threads spin up quickly and all memory comes back, message passing
large shared data structures, making sure the inbox doesn't explode,
timestamping messages from multiple senders to one receiver,
race/deadlock/starving, _that_ devil is in _those_ details, and where do you
see the details managed relatively completely?.... OTP behaviors and the other
erlang stuff.

I think here, as with many things i would characgterize as large architectural
language features, it's important to see the limitations of STm (I think Duffy
talked about htis in the STM/C# postmortem), the tradeoff between number of
variables in the transaction, size/complexity of read/writes (e.g. putting
collections or btrees in transactions), and number of threads reading /writing
the TVar every second. GHC i would point out has some impressive STM
benchmarks and I expect akka could do same but tweak a few things in your app
and it will probably perform differently, very probably worse, depending on
how much time you have on your hands.

I was thinkg in the context of the leaked Yammer/scala memo for an uncoming
meetup, what if there were a dozen Rich Hickeys, or 2 dozen Simons for GHC, or
whatever, their languages would still not be perfect, but the imperfections
and myriad interactions of all these lang/runtime features would be clearly
understood.

the issue of timestamping messages, guaranteeing send order, is one of the
unresolved issues with BEAM and akka, and as far as I know, GHC and F#. You
can guarantee send order for one receiver and one sender only. It seems to me
that if you assume only local machines in physical proximity on a LAN, and
assume away latency/partition, you could make some assumptions about message
sending order from several sending processes (erlangese) to one receiver, or
vice versa

~~~
pron
Is Jobim still actively developed?

And while we're on the subject, whatever happened to Erjang?

------
augustl
Here's the link to the original:

[http://channel9.msdn.com/shows/Going+Deep/Expert-to-
Expert-R...](http://channel9.msdn.com/shows/Going+Deep/Expert-to-Expert-Rich-
Hickey-and-Brian-Beckman-Inside-Clojure/)

------
nebaneba
If you watch the introduction, notice that when Rich Hickey motions the lisp
syntax with his hands, he explains prefix notation _in the viewer's
perspective_!

~~~
bitops
He's a fantastic presenter. I've found every single one of his talks extremely
thought-provoking.

