Re: Clojure for big data

[Christopher Small]

Hi Ray

> This is partly prompted by the lack of activity on the Github repos.

Maybe you have higher standards here than I do... last commits on Flambo 
and Sparkling were 3 and 2 months ago, respectively. That doesn't raise any 
alarm bells for me personally. Moreover, looking at the contributor graphs, 
I don't particularly get the impression that the projects have ground to a 
halt:

https://github.com/gorillalabs/sparkling/graphs/contributors
https://github.com/yieldbot/flambo/graphs/contributors

I haven't used either, but I've heard good things from folks who've used 
Flambo. Last I heard, Flambo was a pretty key component of Yieldbot's 
infrastructure, and they seem to be doing well, so I wouldn't expect the 
project to go away any time soon. I don't know as much about Sparkling, but 
it seems to have actually started as a fork of Flambo, so I'd imagine the 
APIs are at least somewhat similar, and if one went defunct, you'd probably 
have a migration path towards the other.

You may also want to take a look at 
Onyx: https://github.com/onyx-platform/onyx. It's written from the ground 
up in Clojure, and is really wonderfully designed, with a very data-centric 
(Clojuric) API. They have a very active Gitter chat room 
(https://gitter.im/onyx-platform/onyx), and the developers are very 
friendly and helpful folks. You should know ahead of time that in contrast 
with Spark and MR, which are "batch centric" technologies, Onyx is 
foundationally a built on a streaming model, with support for typical batch 
processes built on top of this streaming base. IIRC, this is modeled after 
some of the Dataflow work Google has been doing, and due to the shifting 
economics around the cost of data transmission, this approach ends up being 
pretty competitive for batch workflows, while also offering a path towards 
more seamless streaming workflows should such a setup benefit you.

I haven't spent a ton of time on the Clojurians slack channel, or any big 
data Google groups, but there is a Clojure Datascience site/chat room that 
I host which has at least some activity. Most of the chatter there has been 
more on the side of statistics, machine learning, data viz and such, and 
less specifically on big data per se, but we'd welcome you to join and 
broaden the discussion: https://gitter.im/metasoarous/clojure-datascience. 
There's actually been an uptick in activity there since the Conj, and I'd 
love to see that momentum continue.

Good luck

Chris



On Wednesday, October 18, 2017 at 4:03:11 AM UTC-7, Ray Miller wrote:
>
> Hi,
>
> Here at Metail we have been using Clojure for medium-sized data processing 
> on AWS EMR. We started out with Cascalog about 5 years ago, switched to 
> Parkour 2 years ago, and are now considering a move to Spark.
>
> My question is: is Clojure still a good choice for medium/large data 
> processing on EMR?
>
> This is partly prompted by the lack of activity on the Github repos. Are 
> the Parkour, Flambo and Sparkling libraries rock solid, or simply not 
> getting enough use to trigger bugs and feature requests? 
>
> The #bigdata channel over on Clojurians slack is also suspiciously quiet, 
> as are many of the Google groups.
>
> Ray.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: sputter, a Clojure implementation of the Ethereum VM

[Andrea Richiardi]

Nice!

On Wednesday, October 18, 2017 at 8:35:36 AM UTC-7, Moe Aboulkheir wrote:
>
> I've been working on an ongoing series of blog posts documenting the 
> development of sputter , an 
> immutable EVM implementation  Today's instalment is available here 
> .
>
> The first post  
> contains 
> enough background information to get started, for those without prior 
> knowledge of Ethereum.
>
> Take care,
> Moe  
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: why java version in 10 times faster?

[Lubomir Konstantinov]

I was merely pointing that 'equivalent' Java code (and the subsequent 
Clojure one) is not really equivalent to the example and why this explains 
the performance difference. Wasn't really aware that this is a business 
problem in need of algorithmic optimization. If it was, I probably would 
suggest optimizing it to a noop, since, well, random is random.

On Wednesday, 18 October 2017 22:01:41 UTC+3, Mike wrote:
>
> Hello, Lubomir!
>
> The business problem was: Here is vector of vectors, where each subvector 
> contains (initially sequential) unique numbers. Then a set of threads are 
> started that repeatedly select two random positions in two random 
> subvectors and swap them, in a transaction. After N iterations, we should 
> see no values get lost or duplicated in the shuffle.
>
> Both realizations are correct. But, Java version was faster from 10 to 20 
> times. And I decided to investigate why? Changing the locking level from 
> vector to individual number I didn't change the business problem criteria 
> (initial conditions). But now Clojure works with comparable speed with 
> Java. And both are acceptable for business (correctness guaranteed).
>
> For business it is not important what type of locks we are using. But time 
> & money are important. Slow speed from 10 to 20 times it is matters.
>
> My goal is achieved: Clojure code was smaller in 10 times than Java code. 
> ~150 LOC in java vs 15 LOC in Clojure. And now I demonstrated to Java 
> developers that Clojure code is fast enough. But Clojure code is totally 
> simple. If business goals would be changed it is not so easy in Java to put 
> right locks to the right places for new contions. So here is business 
> values for Clojure: 
> - dead simple logic;
> - reduced T2M;
> - less code less bugs;
> - fast enough.
>
> (Sold to business.)
>
> Mike.
>
> среда, 18 октября 2017 г., 20:33:28 UTC+3 пользователь Lubomir 
> Konstantinov написал:
>>
>> Among other things (you are trying to compare two totally different 
>> synchronization mechanisms) - cause its doing something else :)
>>
>> The version from the example is preserving the atomicity of the whole 
>> vector. Your version is working on an element level.
>>
>> In the former, If multiple threads are trying to update same v1 or v2 
>> simultaneously - STM will retry the transaction. In the latter, the 
>> collision needs to be on the same cells as well.
>>
>> On Wednesday, 18 October 2017 11:01:20 UTC+3, Mike wrote:
>>>
>>> Hi, Deniel.
>>>
>>> I made minor change from example (https://clojure.org/reference/refs) 
>>> and now Clojure code works at speed 60-80% of pure Java code.
>>> I changed level of lock (refs). In example of clojure org level of refs 
>>> is higher and that is why code works slower, i.e  [ (ref[ 0 1 2..]) (ref 
>>> [..]) .. ]
>>> I made [ [(ref 0) (ref 1) ...] [ ref ...] ...] and now it is flying.
>>>
>>> Here is the code:
>>>
>>> (defn run [nvecs nitems nthreads niters]
>>>   (let [vec-refs (vec (map vec (partition nitems (map ref (range (* 
>>> nvecs nitems))
>>> swap #(let [v1 (rand-int nvecs)
>>> v2 (rand-int nvecs)
>>> i1 (rand-int nitems)
>>> i2 (rand-int nitems)]
>>> (dosync
>>>  (let [temp @(nth (vec-refs v1) i1)]
>>>(ref-set (nth (vec-refs v1) i1)  @(nth (vec-refs v2) 
>>> i2))
>>>(ref-set (nth (vec-refs v2) i2) temp
>>> report #(do 
>>>   (println "Distinct:"
>>>(count (distinct (map deref (apply concat 
>>> vec-refs))]
>>> (dorun (apply pcalls (repeat nthreads #(dotimes [_ niters] (swap)
>>> (report)))
>>>
>>> вторник, 17 октября 2017 г., 0:19:26 UTC+3 пользователь Daniel Compton 
>>> написал:

 Hi Mike

 A few thoughts

 * In my experience it is not unusual that idiomatic Clojure could be 
 10x slower than the equivalent Java.
 * Where did you do your timing on the ref calculation? In the Clojure 
 version it calculates distinct at the end.
 * How did you do your benchmarking? JVM benchmarking is very tricky, 
 and could easily overwhelm all other results.
 * Have you verified that your Java code is correct under all situations?

 Overall I think this is a good illustration of a tradeoff that Clojure 
 makes against Java. Idiomatic Clojure code is often slower than the Java 
 that one might write. However (to my eyes) it is far easier to read, 
 understand, and crucially to verify correctness even on the small example 
 of swapping numbers. Most of the time, for most systems this is a good 
 tradeoff. Ensuring correctness and performance with locks in a larger 
 concurrent system becomes even more difficult. 

 However if performance is critical, and you have the time and skill to 
 verify that your locking algorithm is correct, then you can always use 
>>>

Re: why java version in 10 times faster?

[Mike]

Hello, Lubomir!

The business problem was: Here is vector of vectors, where each subvector 
contains (initially sequential) unique numbers. Then a set of threads are 
started that repeatedly select two random positions in two random 
subvectors and swap them, in a transaction. After N iterations, we should 
see no values get lost or duplicated in the shuffle.

Both realizations are correct. But, Java version was faster from 10 to 20 
times. And I decided to investigate why? Changing the locking level from 
vector to individual number I didn't change the business problem criteria 
(initial conditions). But now Clojure works with comparable speed with 
Java. And both are acceptable for business (correctness guaranteed).

For business it is not important what type of locks we are using. But time 
& money are important. Slow speed from 10 to 20 times it is matters.

My goal is achieved: Clojure code was smaller in 10 times than Java code. 
~150 LOC in java vs 15 LOC in Clojure. And now I demonstrated to Java 
developers that Clojure code is fast enough. But Clojure code is totally 
simple. If business goals would be changed it is not so easy in Java to put 
right locks to the right places for new contions. So here is business 
values for Clojure: 
- dead simple logic;
- reduced T2M;
- less code less bugs;
- fast enough.

(Sold to business.)

Mike.

среда, 18 октября 2017 г., 20:33:28 UTC+3 пользователь Lubomir Konstantinov 
написал:
>
> Among other things (you are trying to compare two totally different 
> synchronization mechanisms) - cause its doing something else :)
>
> The version from the example is preserving the atomicity of the whole 
> vector. Your version is working on an element level.
>
> In the former, If multiple threads are trying to update same v1 or v2 
> simultaneously - STM will retry the transaction. In the latter, the 
> collision needs to be on the same cells as well.
>
> On Wednesday, 18 October 2017 11:01:20 UTC+3, Mike wrote:
>>
>> Hi, Deniel.
>>
>> I made minor change from example (https://clojure.org/reference/refs) 
>> and now Clojure code works at speed 60-80% of pure Java code.
>> I changed level of lock (refs). In example of clojure org level of refs 
>> is higher and that is why code works slower, i.e  [ (ref[ 0 1 2..]) (ref 
>> [..]) .. ]
>> I made [ [(ref 0) (ref 1) ...] [ ref ...] ...] and now it is flying.
>>
>> Here is the code:
>>
>> (defn run [nvecs nitems nthreads niters]
>>   (let [vec-refs (vec (map vec (partition nitems (map ref (range (* nvecs 
>> nitems))
>> swap #(let [v1 (rand-int nvecs)
>> v2 (rand-int nvecs)
>> i1 (rand-int nitems)
>> i2 (rand-int nitems)]
>> (dosync
>>  (let [temp @(nth (vec-refs v1) i1)]
>>(ref-set (nth (vec-refs v1) i1)  @(nth (vec-refs v2) 
>> i2))
>>(ref-set (nth (vec-refs v2) i2) temp
>> report #(do 
>>   (println "Distinct:"
>>(count (distinct (map deref (apply concat 
>> vec-refs))]
>> (dorun (apply pcalls (repeat nthreads #(dotimes [_ niters] (swap)
>> (report)))
>>
>> вторник, 17 октября 2017 г., 0:19:26 UTC+3 пользователь Daniel Compton 
>> написал:
>>>
>>> Hi Mike
>>>
>>> A few thoughts
>>>
>>> * In my experience it is not unusual that idiomatic Clojure could be 10x 
>>> slower than the equivalent Java.
>>> * Where did you do your timing on the ref calculation? In the Clojure 
>>> version it calculates distinct at the end.
>>> * How did you do your benchmarking? JVM benchmarking is very tricky, and 
>>> could easily overwhelm all other results.
>>> * Have you verified that your Java code is correct under all situations?
>>>
>>> Overall I think this is a good illustration of a tradeoff that Clojure 
>>> makes against Java. Idiomatic Clojure code is often slower than the Java 
>>> that one might write. However (to my eyes) it is far easier to read, 
>>> understand, and crucially to verify correctness even on the small example 
>>> of swapping numbers. Most of the time, for most systems this is a good 
>>> tradeoff. Ensuring correctness and performance with locks in a larger 
>>> concurrent system becomes even more difficult. 
>>>
>>> However if performance is critical, and you have the time and skill to 
>>> verify that your locking algorithm is correct, then you can always use 
>>> locks. Either through direct calls to Java interop, or writing your locking 
>>> code in Java and calling that via Java interop.
>>>
>>> For more info on this, you can read the conversation between Rich 
>>> Hickey and Cliff Click about STMs vs Locks 
>>> 
>>> .
>>>
>>> --
>>> Daniel.
>>>
>>> On Mon, Oct 16, 2017 at 7:44 PM Mike <145...@gmail.com> wrote:
>>>
 https://clojure.org/reference/refs correct link


 -- 
 Yo

Re: why java version in 10 times faster?

[Lubomir Konstantinov]

Among other things (you are trying to compare two totally different 
synchronization mechanisms) - cause its doing something else :)

The version from the example is preserving the atomicity of the whole 
vector. Your version is working on an element level.

In the former, If multiple threads are trying to update same v1 or v2 
simultaneously - STM will retry the transaction. In the latter, the 
collision needs to be on the same cells as well.

On Wednesday, 18 October 2017 11:01:20 UTC+3, Mike wrote:
>
> Hi, Deniel.
>
> I made minor change from example (https://clojure.org/reference/refs) and 
> now Clojure code works at speed 60-80% of pure Java code.
> I changed level of lock (refs). In example of clojure org level of refs is 
> higher and that is why code works slower, i.e  [ (ref[ 0 1 2..]) (ref [..]) 
> .. ]
> I made [ [(ref 0) (ref 1) ...] [ ref ...] ...] and now it is flying.
>
> Here is the code:
>
> (defn run [nvecs nitems nthreads niters]
>   (let [vec-refs (vec (map vec (partition nitems (map ref (range (* nvecs 
> nitems))
> swap #(let [v1 (rand-int nvecs)
> v2 (rand-int nvecs)
> i1 (rand-int nitems)
> i2 (rand-int nitems)]
> (dosync
>  (let [temp @(nth (vec-refs v1) i1)]
>(ref-set (nth (vec-refs v1) i1)  @(nth (vec-refs v2) 
> i2))
>(ref-set (nth (vec-refs v2) i2) temp
> report #(do 
>   (println "Distinct:"
>(count (distinct (map deref (apply concat 
> vec-refs))]
> (dorun (apply pcalls (repeat nthreads #(dotimes [_ niters] (swap)
> (report)))
>
> вторник, 17 октября 2017 г., 0:19:26 UTC+3 пользователь Daniel Compton 
> написал:
>>
>> Hi Mike
>>
>> A few thoughts
>>
>> * In my experience it is not unusual that idiomatic Clojure could be 10x 
>> slower than the equivalent Java.
>> * Where did you do your timing on the ref calculation? In the Clojure 
>> version it calculates distinct at the end.
>> * How did you do your benchmarking? JVM benchmarking is very tricky, and 
>> could easily overwhelm all other results.
>> * Have you verified that your Java code is correct under all situations?
>>
>> Overall I think this is a good illustration of a tradeoff that Clojure 
>> makes against Java. Idiomatic Clojure code is often slower than the Java 
>> that one might write. However (to my eyes) it is far easier to read, 
>> understand, and crucially to verify correctness even on the small example 
>> of swapping numbers. Most of the time, for most systems this is a good 
>> tradeoff. Ensuring correctness and performance with locks in a larger 
>> concurrent system becomes even more difficult. 
>>
>> However if performance is critical, and you have the time and skill to 
>> verify that your locking algorithm is correct, then you can always use 
>> locks. Either through direct calls to Java interop, or writing your locking 
>> code in Java and calling that via Java interop.
>>
>> For more info on this, you can read the conversation between Rich Hickey 
>> and Cliff Click about STMs vs Locks 
>> 
>> .
>>
>> --
>> Daniel.
>>
>> On Mon, Oct 16, 2017 at 7:44 PM Mike <145...@gmail.com> wrote:
>>
>>> https://clojure.org/reference/refs correct link
>>>
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clo...@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with 
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+u...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to clojure+u...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] ClojureTab-1.5 plugin for Protege

[ru]

Dear Clojure users!

ClojureTab-1.5 plugin for Protege (https://protege.stanford.edu/) published 
on Protege Plugin Library 
page: https://protegewiki.stanford.edu/wiki/ClojureTab

Features:
1. Integrated development environment for Clojure language
2. Protege API for Clojure language
3. Rule engine and Expert system shell rete4frames 
(https://github.com/rururu/rete4frames)
4. Algorithms visual development environment 
   (short screencast 
(https://www.youtube.com/watch?v=oRCMw_rnLvg&feature=youtu.be), 
long screencast 
(https://www.youtube.com/watch?v=exca_ac2bj4&feature=youtu.be))

Homepage of ClojureTab project: https://github.com/rururu/r4f-pro

Sincerely,
  Ru

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ANN: sputter, a Clojure implementation of the Ethereum VM

[Moe Aboulkheir]

I've been working on an ongoing series of blog posts documenting the
development of sputter , an
immutable EVM implementation  Today's instalment is available here
.

The first post 
contains
enough background information to get started, for those without prior
knowledge of Ethereum.

Take care,
Moe

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nice screencast overview of Specter

[Alan Thompson]

I just saw this on YouTube and thought you may enjoy it:
https://youtu.be/rh5J4vacG98

While there is lots of written documentation on Specter, the live-coding
and narration of what one is seeing provides some nice examples.

Enjoy,
Alan

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Clojure for big data

[Ray Miller]

Hi,

Here at Metail we have been using Clojure for medium-sized data processing
on AWS EMR. We started out with Cascalog about 5 years ago, switched to
Parkour 2 years ago, and are now considering a move to Spark.

My question is: is Clojure still a good choice for medium/large data
processing on EMR?

This is partly prompted by the lack of activity on the Github repos. Are
the Parkour, Flambo and Sparkling libraries rock solid, or simply not
getting enough use to trigger bugs and feature requests?

The #bigdata channel over on Clojurians slack is also suspiciously quiet,
as are many of the Google groups.

Ray.

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: why java version in 10 times faster?

[Mike]

Hi, Deniel.

I made minor change from example (https://clojure.org/reference/refs) and 
now Clojure code works at speed 60-80% of pure Java code.
I changed level of lock (refs). In example of clojure org level of refs is 
higher and that is why code works slower, i.e  [ (ref[ 0 1 2..]) (ref [..]) 
.. ]
I made [ [(ref 0) (ref 1) ...] [ ref ...] ...] and now it is flying.

Here is the code:

(defn run [nvecs nitems nthreads niters]
  (let [vec-refs (vec (map vec (partition nitems (map ref (range (* nvecs 
nitems))
swap #(let [v1 (rand-int nvecs)
v2 (rand-int nvecs)
i1 (rand-int nitems)
i2 (rand-int nitems)]
(dosync
 (let [temp @(nth (vec-refs v1) i1)]
   (ref-set (nth (vec-refs v1) i1)  @(nth (vec-refs v2) i2))
   (ref-set (nth (vec-refs v2) i2) temp
report #(do 
  (println "Distinct:"
   (count (distinct (map deref (apply concat 
vec-refs))]
(dorun (apply pcalls (repeat nthreads #(dotimes [_ niters] (swap)
(report)))

вторник, 17 октября 2017 г., 0:19:26 UTC+3 пользователь Daniel Compton 
написал:
>
> Hi Mike
>
> A few thoughts
>
> * In my experience it is not unusual that idiomatic Clojure could be 10x 
> slower than the equivalent Java.
> * Where did you do your timing on the ref calculation? In the Clojure 
> version it calculates distinct at the end.
> * How did you do your benchmarking? JVM benchmarking is very tricky, and 
> could easily overwhelm all other results.
> * Have you verified that your Java code is correct under all situations?
>
> Overall I think this is a good illustration of a tradeoff that Clojure 
> makes against Java. Idiomatic Clojure code is often slower than the Java 
> that one might write. However (to my eyes) it is far easier to read, 
> understand, and crucially to verify correctness even on the small example 
> of swapping numbers. Most of the time, for most systems this is a good 
> tradeoff. Ensuring correctness and performance with locks in a larger 
> concurrent system becomes even more difficult. 
>
> However if performance is critical, and you have the time and skill to 
> verify that your locking algorithm is correct, then you can always use 
> locks. Either through direct calls to Java interop, or writing your locking 
> code in Java and calling that via Java interop.
>
> For more info on this, you can read the conversation between Rich Hickey 
> and Cliff Click about STMs vs Locks 
> 
> .
>
> --
> Daniel.
>
> On Mon, Oct 16, 2017 at 7:44 PM Mike <145...@gmail.com > 
> wrote:
>
>> https://clojure.org/reference/refs correct link
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clo...@googlegroups.com 
>> 
>> Note that posts from new members are moderated - please be patient with 
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+u...@googlegroups.com 
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to clojure+u...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.