Clojurians Log v2

CfP for :clojureD 2016 is open (until end of Nov.): http://www.clojured.de/call-for-proposals/

It was mentioned on the Ruby mailing list that Blacklane (Limousine service, seems to be based in Schöneberg) has a "huge gathering room that is quite nice"

I don't know what their stack looks like, but this is their head of engineering. Mostly a Ruby person, but mentions "Go, Clojure or Elixir and I find myself more and more interested into functional programming." https://de.linkedin.com/pub/timo-r%C3%B6%C3%9Fner/30/b16/5a

so, could be something worth checking as a potential location for the monthly meetup

@plexus: We have actually been there once :simple_smile:

ah didn't know :simple_smile: ok nevermind

@plexus: thanks though! Appreciate it :simple_smile:

do you have any candidates already for next month?

I was at the distributed matters conference on Saturday, lots of Clojure love there... I blogged about it here: http://jstaffans.github.io/2015/09/20/distributed-matters.html if anyone's interested. Joe Nash of Braintree mentioned that they did lots of GC tuning to improve the performance of their Clojure app. One of the things he mentioned was that when dealing with something like Clojure, which has lots of small objects, GC benefits from having a small heap. That struck me as odd because I always thought having lots of heap is good for GC (more leeway and so on). Does anyone have any insights on that? Joe left before I had a chance to ask him what he meant ..

I was gonna say that a smaller heap might make GC more predictable, because you get more short runs instead of big GC runs that block your app. But in the JVM GC can happen in parallel, it doesn't block the whole VM, so not sure if that applies.

Good point @plexus, that was indeed true for the previous JVM GC generation (concurrent-mark-sweep). The new G1GC is however specifically designed for short pauses and that is what Joe said they are using too..