Poll: which language is better suited for JVM concurrency?
Concurrency programming is difficult to get right– when I mused that I was concerned “that nobody really cares”, I was pleasantly surprised by a series of comments which serve to highlight the issue at hand; that is, CPU architectures are evolving, man, and Java’s concurrency model might not fit the bill.
For instance, Brian Goetz, author of Java Concurrency in Practice
…the trend [with CPU design] is towards weaker memory models, so programs that have “worked” for years will start breaking as we deploy on new generations of hardware.
What’s more, Christian Vest Hansen aptly pointed out that
In my experience, people realize that they don’t know enough to deal with concurrency, so they try to avoid writing code where they have to deal with it directly. But they don’t realize that their lack of knowledge on concurrency actually makes it near impossible for them to write code that is devoid of the concurrency they sought to dodge.
And Kirk Pepperdine commented
Any time you access data that is being shared with other threads/processes, you are programming concurrently. So, developers are already writing concurrent code albeit accidentally. This typically results in some very strange bugs. More over, the tools that we have today aren’t very helpful in helping to resolve these issues which makes them difficult if not impossible to resolve.
Accordingly, future versions of Java are targeting improved concurrency features. Nevertheless, Java’s concurrency design is fundamentally different than other languages, such as Erlang, which has no notion of shared memory (consequently, there are no needs for locks, for example). Erlang isn’t the only language built with concurrency in mind, however. Relative newcomers, Scala and Clojure also address concurrency programming and all three languages are capable of running (in some form or another) on the JVM. Thus, if it’s your bag, you can address concurrency challenges now.
Given these three languages (plus future versions of Java) then, which one is better suited for concurrent programming on the JVM?
| Related odds and ends | ||
|---|---|---|
9 comments Sunday 19 Oct 2008 | Software Development
9 Responses to “Poll: which language is better suited for JVM concurrency?”
Erlang does not run on the JVM. This allows the language to create as many lightweight concurrent threads/processes as needed.
Giorgio-
Indeed, man, good point– I was referring to JInterface when I said “in some form or another” but in reality, in JInterface’s case, true Erlang code isn’t running on the JVM. Thanks for pointing that out!
Groovy for me
If a person has enough experience in all of those to answer this question, I’d be very surprised and highly impressed.
I just don’t understand this claim:
>Java’s concurrency model might not fit the bill
If it is justified by Goetz simply stating that old, erroneous programs that happened to work in the past will start to break, then it makes no sense. Goetz is talking about programs with *bugs*. Only broken programs need to be aware of the danger of breaking in new platforms. Coding to the Java memory model means high portability across platforms and architectures – you need to understand that the memory model is an abstraction to be implemented by the various platform jvms, i.e. it does not directly expose the underlying architecture, but it abstracts it.
Also note that programs that were correct with the older memory model (i.e. before Java 5), are also correct with the new one.
Finally, since the memory model is not expected to further evolve at least in the foreseable future, I don’t understand what you mean you expect from future versions of Java. Better /libraries/ maybe? But then that’s irrelevant to Java, isn’t it.
Why this web site do not have other languages support?
[...] this dovetails nicely with the ongoing results of a recent unscientific poll, entitled “which language is better suited for JVM concurrency?” which has Scala in the clear lead (36% of the vote as compared to Clojure’s [...]
[...] situations with various libraries and frameworks on the JVM (either straight Java or via Groovy), Scala has always held my interest in that the language is functional by nature — that is, [...]
great nice article