4 ms·

I'd suggest that you're being a bit ideologically biased against Java. Ain't no easier language to do concurrent programming, aside from Clojure (jvm), Scala (

by jbooth 15y ago

I'd suggest that you're being a bit ideologically biased against Java. Ain't no easier language to do concurrent programming, aside from Clojure (jvm), Scala (jvm) and I hear Erlang (don't know much about it). Every serious project in Clojure or Scala that I've seen ignores their concurrency stuff and goes straight to Java. It turns out that if you implement a bunch of Callables and ExecutorServices with LinkedBlockingQueues or SynchronousQueues.. it's basically functional programming. Don't get too hung up on the syntax.

gtani 15y ago
concurrency stuff You're talking about at least 3 distinct models: direct thread management, with improved locking routines (java.util.concurrent, see recent Prismatic thread on HN), actors/green threads (Akka and erlang BEAM), and STM/guarded read/writes (clojure, and you should read about Microsoft's attempt to graft STM onto C#, Joe Duffy's blog)
- jbooth 15y ago
  java.util.concurrent's entire point is to make direct thread management unnecessary. Note the list of classes I mentioned didn't include Thread. Actors and STM are great thought experiments but real-world production stuff tends to always circumvent them for the java.util.concurrent stuff.
  - dxbydt 15y ago
    >Actors and STM are great thought experiments but real-world production stuff tends to always circumvent them for the java.util.concurrent stuff. Its a mixed picture, if you want to be honest. There are places like bofa where I've pushed into production a cvar processing module on 500,000 loans which uses only actors. No low level tinkering with util.concurrent, no Threadpool setting, no Executors, no synchronized anywhere in my code. In the past at GS, I wrote concurrent code where I explicitly specified the number of threads & we had a ThreadPool manager & internally it used the util.concurrent classes. At LinkedIn, I believe they started with actors & switched parts of it to Doug Lea's framework ( which was the sort of the foundation of util.concurrent). I have seen financial shops where they do half & half - the quants seem to like actors but the swing programmers like to have control on threadcounts, & they tend to do things like naming threads & creating parent-child relationships so swing can paint reliably & they can debug threads by name when it doesn't. I did the same in the past when most of my work was on the swing side, creating custom blotters to show trade tickets & the like. But now I primarily do quant model building work with actors & no more util.concurrent stuff. If you want to construct a lattice model to price structured options on a 100 different strikes per month for 5 years in advance, you can find no better friend than an actor. Actors are certainly not a thought experiment, very much a reality.
    - jbooth 15y ago
      Great post, yeah I overstated a little bit and actors are certainly valid for certain cases. I was just reacting to what I saw as an overstatement on the other side.
  - gruseom 15y ago
    You've made this point twice now ("Every serious project in Clojure or Scala that I've seen ignores their concurrency stuff and goes straight to Java") and I'm curious to hear some examples as well as your understanding of why this would be.
    - jbooth 15y ago
      For examples, the most recent ones I've seen are linkedin's kafka (scala), and bradford cross's recent post regarding clojure at prismatic (and other posts I've seen regarding both). For why, I'd assume that they found the abstractions were getting in their way. java.util.concurrent is sort of the minimum abstraction (IMO) between nicer constructs and OS-level threads.
michaelochurch 15y ago
My problem with Java is the language. Scala and Clojure are great. The platform is excellent technology. The language is mind-numbingly boring. When Scala and Clojure projects go "straight to Java", it's generally for specialized purposes (where those languages don't have native maturity) or in already-discovered bottlenecks. I think some degree of that's inevitable. Like database tuning, it's just something you have to do when you get to a certain point where (a) your problem is well-defined, and (b) shaving 20% off latency is worth doing. I consider these good problems to have. If I have to rewrite a class in Java for performance reasons, fine. I'd never start a multi-thousand-line project in Java, though. Also, I really don't think anyone mature minds writing code in underpowered or difficult languages. C++, I find, is actually a lot of fun to write. It's reading other peoples' code, in large amounts, that becomes intolerable in these languages. If I have to spend a day to answer a simple question like "how do I initialize this object?", that's bad. Interesting fact: Closures were cut from the 1.0 release for time. Gosling wanted them in, but Java's original purpose was to run in machines like automatic coffee pots and TV "set top boxes", so they were far from essential for that domain. The folk history (which I once believed) of Java being deliberately underpowered so that teams of hundreds of mediocre programmers could be stapled together in it is false. It was, however, co-opted by the "let's commoditize developers" crowd in the late '90s, and we've had to deal with FactoryVisitorDelegates ever since.
- dxbydt 15y ago
  > Java's original purpose was to run in machines like automatic coffee pots and TV "set top boxes from my time at sun, i remember speeches by Gosling that included microwaves and refrigerators ( i vaguely recall an example of the fridge telling you via java applet that you had run out of milk ). the hotjava thing ( web browser written entirely in java http://en.wikipedia.org/wiki/HotJava http://en.wikipedia.org/wiki/HotJava) created some anticipation around Word & Photoshop & Powerpoint written in java, which were brought up when Sun hosted a gigantic industry conference in Vegas. The Java Chip ( picojava http://www.jopdesign.com/perf.jsp http://www.jopdesign.com/perf.jsp ) was supposed to revolutionize the industry by running java bytecode natively. Honestly I think the dumbing down began once EJB's crept in. There was some nasty visual shit called the Beantool which automatically inserted getters & setters by mandating every EJB to be a Bean, and from then on things got downhill really fast.
dxbydt 15y ago
That bias is very much justified, I'd say. scala> (1 to 10).par.foreach(x=>print(x*x+",")) 4,9,1,49,36,16,81,25,64,100, Let me know how you'd parallelize the above in Java, how many lines of code it'll take, what syntactic constructs you'd end up using, what libraries you'd import, and finally your my mental model would be - in terms of locks and semaphores and so forth. The thing with scala is that concurrency - both data parallelism ( above example ) and task parallelism ( using actors in scala, a slightly longer example) are baked right into the language. A newbie in concurrency whose mental model doesn't incorporate thread pools or executor services or synchronous queues can progress leaps & bounds in scala vs java when it comes to concurrency.
- jbooth 15y ago
  Ideological bias is never justified. On to the justified bias: For that problem, I'd just do it serially, because it's only 10 numbers. Oh, it was an example for really big sets of numbers? Like really really big? Then I'd skip the .par.foreach and deal with java.util.concurrent directly, because it's worth my while if I have a serious problem worth optimizing. "A newbie in concurrency whose mental model doesn't incorporate thread pools or executor services or synchronous queues can progress leaps & bounds in scala vs java when it comes to concurrency." A newbie in concurrency needs to understand how many threads are in their threadpool, or else they should just do it serially. I'm not talking rocket science here, it's just a single integer argument.

by jbooth 15y ago

gtani 15y ago

concurrency stuff You're talking about at least 3 distinct models: direct thread management, with improved locking routines (java.util.concurrent, see recent Prismatic thread on HN), actors/green threads (Akka and erlang BEAM), and STM/guarded read/writes (clojure, and you should read about Microsoft's attempt to graft STM onto C#, Joe Duffy's blog)

jbooth 15y ago
java.util.concurrent's entire point is to make direct thread management unnecessary. Note the list of classes I mentioned didn't include Thread. Actors and STM are great thought experiments but real-world production stuff tends to always circumvent them for the java.util.concurrent stuff.
- dxbydt 15y ago
  >Actors and STM are great thought experiments but real-world production stuff tends to always circumvent them for the java.util.concurrent stuff. Its a mixed picture, if you want to be honest. There are places like bofa where I've pushed into production a cvar processing module on 500,000 loans which uses only actors. No low level tinkering with util.concurrent, no Threadpool setting, no Executors, no synchronized anywhere in my code. In the past at GS, I wrote concurrent code where I explicitly specified the number of threads & we had a ThreadPool manager & internally it used the util.concurrent classes. At LinkedIn, I believe they started with actors & switched parts of it to Doug Lea's framework ( which was the sort of the foundation of util.concurrent). I have seen financial shops where they do half & half - the quants seem to like actors but the swing programmers like to have control on threadcounts, & they tend to do things like naming threads & creating parent-child relationships so swing can paint reliably & they can debug threads by name when it doesn't. I did the same in the past when most of my work was on the swing side, creating custom blotters to show trade tickets & the like. But now I primarily do quant model building work with actors & no more util.concurrent stuff. If you want to construct a lattice model to price structured options on a 100 different strikes per month for 5 years in advance, you can find no better friend than an actor. Actors are certainly not a thought experiment, very much a reality.
  - jbooth 15y ago
    Great post, yeah I overstated a little bit and actors are certainly valid for certain cases. I was just reacting to what I saw as an overstatement on the other side.
- gruseom 15y ago
  You've made this point twice now ("Every serious project in Clojure or Scala that I've seen ignores their concurrency stuff and goes straight to Java") and I'm curious to hear some examples as well as your understanding of why this would be.
  - jbooth 15y ago
    For examples, the most recent ones I've seen are linkedin's kafka (scala), and bradford cross's recent post regarding clojure at prismatic (and other posts I've seen regarding both). For why, I'd assume that they found the abstractions were getting in their way. java.util.concurrent is sort of the minimum abstraction (IMO) between nicer constructs and OS-level threads.

michaelochurch 15y ago

My problem with Java is the language. Scala and Clojure are great. The platform is excellent technology. The language is mind-numbingly boring. When Scala and Clojure projects go "straight to Java", it's generally for specialized purposes (where those languages don't have native maturity) or in already-discovered bottlenecks. I think some degree of that's inevitable. Like database tuning, it's just something you have to do when you get to a certain point where (a) your problem is well-defined, and (b) shaving 20% off latency is worth doing. I consider these good problems to have. If I have to rewrite a class in Java for performance reasons, fine. I'd never start a multi-thousand-line project in Java, though. Also, I really don't think anyone mature minds writing code in underpowered or difficult languages. C++, I find, is actually a lot of fun to write. It's reading other peoples' code, in large amounts, that becomes intolerable in these languages. If I have to spend a day to answer a simple question like "how do I initialize this object?", that's bad. Interesting fact: Closures were cut from the 1.0 release for time. Gosling wanted them in, but Java's original purpose was to run in machines like automatic coffee pots and TV "set top boxes", so they were far from essential for that domain. The folk history (which I once believed) of Java being deliberately underpowered so that teams of hundreds of mediocre programmers could be stapled together in it is false. It was, however, co-opted by the "let's commoditize developers" crowd in the late '90s, and we've had to deal with FactoryVisitorDelegates ever since.

dxbydt 15y ago
> Java's original purpose was to run in machines like automatic coffee pots and TV "set top boxes from my time at sun, i remember speeches by Gosling that included microwaves and refrigerators ( i vaguely recall an example of the fridge telling you via java applet that you had run out of milk ). the hotjava thing ( web browser written entirely in java http://en.wikipedia.org/wiki/HotJava http://en.wikipedia.org/wiki/HotJava) created some anticipation around Word & Photoshop & Powerpoint written in java, which were brought up when Sun hosted a gigantic industry conference in Vegas. The Java Chip ( picojava http://www.jopdesign.com/perf.jsp http://www.jopdesign.com/perf.jsp ) was supposed to revolutionize the industry by running java bytecode natively. Honestly I think the dumbing down began once EJB's crept in. There was some nasty visual shit called the Beantool which automatically inserted getters & setters by mandating every EJB to be a Bean, and from then on things got downhill really fast.

dxbydt 15y ago

That bias is very much justified, I'd say. scala> (1 to 10).par.foreach(x=>print(x*x+",")) 4,9,1,49,36,16,81,25,64,100, Let me know how you'd parallelize the above in Java, how many lines of code it'll take, what syntactic constructs you'd end up using, what libraries you'd import, and finally your my mental model would be - in terms of locks and semaphores and so forth. The thing with scala is that concurrency - both data parallelism ( above example ) and task parallelism ( using actors in scala, a slightly longer example) are baked right into the language. A newbie in concurrency whose mental model doesn't incorporate thread pools or executor services or synchronous queues can progress leaps & bounds in scala vs java when it comes to concurrency.

jbooth 15y ago
Ideological bias is never justified. On to the justified bias: For that problem, I'd just do it serially, because it's only 10 numbers. Oh, it was an example for really big sets of numbers? Like really really big? Then I'd skip the .par.foreach and deal with java.util.concurrent directly, because it's worth my while if I have a serious problem worth optimizing. "A newbie in concurrency whose mental model doesn't incorporate thread pools or executor services or synchronous queues can progress leaps & bounds in scala vs java when it comes to concurrency." A newbie in concurrency needs to understand how many threads are in their threadpool, or else they should just do it serially. I'm not talking rocket science here, it's just a single integer argument.