Clojure

Everybody knows concurrent programming is the next big thing. Even the GTA guys running on the PS3 are realizing it, if belatedly (damn that cell processor!). Too bad really, that no body actually knows how to do concurrent programming. That is... without causing the machine to blow up.
What's wrong with the locking model? you might ask. Well... as I understand it, the locking model suffers from a lack of composeability; whatever that means. What's ultimately the problem is that the locking model is hard to think about; it's hard to say for certain when a lock is going to be held, and to determine if your operations are ever going to interleave and cause inconsistent state.
The alternatives to the locking model, the actor model and the transactional memory model, are definitely worth looking at. While I was screwing around with the Scala programming language, I made use of their nice Actor library to do a bit of multithreading, and I kindof like it. The only problem with it is the asynchronousness of actors (which is an inherent aspect of actors), which can lead (especially in a language without first class functions) to some really ugly callback style spaghetti, imho. I actually tried to implement a program with asynchronous io purely in java at one point, and it was soooo ugly I just had to stop. Don't be fooled, anonymous inner classes are no substitute for first class functions.
Obviously the inner class ugliness is not an issue with scala, which has great support for first class functions, but nevertheless having to think about a program, and design a program according to an asynchronous model is (I think) more of a challenge than the more traditional sequential imperative crap: this happens, then that happens, then that happens, etcetera.
Software Transactional Memory has been called the silver bullet (I heard it on java posse!), because at face value it appears to solve all the concurrency problems by making it (almost) transparant to the programmer. STM is nestable, and it appears chipmakers are starting or planning to build support for it directly in the hardware. But... for whatever reason, there are some issues that it may bring up, which I do not understand enough to talk cogently about.
Clojure, a strongly functional dialect of lisp, has a built in STM facility, and I really look forward to trying it out on a multithreaded program. Truthfully I have tried it out a little, but I without using it a larger concurrent program I can't say how great it is. Rich Hickey, the creator of Clojure, has this ant simulation that's pretty cool: each ant has a thread, and they all coexist on in this field of food and pheromones--the STM, concisely applied, keeps them all consistent.
I really like Clojure, mostly because it's a lisp dialect on the JVM, and I'm really warming up to the power of lisp. I just got finished doing some GUI programming and it is totally astonishing how much having lisp macros improves the process of GUI coding: which for me, is normally the worst possible kind of coding I would never want to voluntarily engage in. Swing especially, in Java, tends to be soooooo repetative and boilerplate, lacking all the declaritive goodness and conciseness found in html and css or even something like JSF, I really have trouble keeping from banging my head against the wall. But, with lisp, I can write macros that let me write my widgets in a declarative style, and do all the nasty gnarly conversions on the backend for me. This is really the extraordinary power of DSLs and metaprogramming made easy. This is why people love Lisp, because it can take a tedious boilerplate coding task, and strip away all the useless crap, leaving just the ideas.