Hacker News Reader

While cool,but really, Is there such a great clamoring for scaling programs over multiple cores

Absolutely. Queues, databases, caches, machine learning, graph algorithms, CRDTs, image, audio, and video processing, stream algorithms, analytics, geospatial work, even HTTP APIs: all demand compute performance. Since CPU flops have been essentially stagnant for ten years, the only way to improve performance on commodity hardware is with parallelism. Almost every program I've worked on in the last five years has demanded multicore programming, or at least in-process concurrency.

Clojure is not the fastest language out there, but it does make reasoning about concurrent code dramatically simpler than other languages. My Clojure programs tend to parallelize trivially over 16 or 32 cores, and only rarely contain race conditions, deadlocks, or other threading bugs. In contrast, I routinely struggle to write correct multithreaded code in Java, and when I do, I usually adopt a slower locking mechanism because I'm just not smart enough to reason about concurrent mutable state.

Why is Clojure better for writing concurrent programs? For one, it's multi-paradigm. You can serialize transformations over state using normal JVM locks, agents, atoms, refs, or promises. Immutable shared-structure objects make concurrency safety trivial--but Clojure's identity types make reasoning about state easy, instead of having to express everything through monadic composition. For mutable state, you've got java.util.concurrent and Cliff Click's high_scale_lib available, plus great libraries like Netty. It's a deeply pragmatic language where the defaults are safe, but controlled speed is available where you need it.

Or you could run 64 Unicorn/V8 workers per node, and push all the hard problems into the database. That's a totally valid strategy--but I think there's a little more to life than that. ;-)

Game programmers are especially unlikely to use Clojure for several reasons:

* New programming practices are adapted after the mainstream programming industry has adopted them.

* Java is not widely used, partially because when the great Java enterprise switch happened, game studios were still debating if switching to C++ was worth it.

* Because games deal with rapid state changes, switching from relatively intuitive object-oriented designs to functional designs requires a rethink of how most game engines operate.

* If it doesn't work on the consoles, the mainstream industry is much less likely to use it. Java isn't natively supported, and Microsoft is unlikely to add anything to the XBox to make it easier.

* Most games are still single-threaded 32-bit Windows applications interfacing with DirectX.

But they are willing to use Haskell, :)

http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-...

https://twitter.com/id_aa_carmack/status/331918309916295168

Not really, no.

Porting a 20 year old game for fun in Haskell doesn't mean that Haskell is ready for the cutting edge of modern games.

They don't need to develop the next Crysis on Haskell to make it accepted.

The plain fact that important personalities in the AAA games industry are willing to spend their valuable time coding something in Haskell instead of doing something else, means a lot.

For example, are you aware that quite a few studios are now using Erlang for their MMO servers?

>I think the whole multiple core thing is over blown in association with functional programming. I think it would be pretty misguided for someone to adopt a functional programming with multiple cores in mind.

The multiple core thing, it not overblown. Clock speed scaling ended a few years ago. Single thread performance scaling is dead, and we need a paradigm shift to deal with the multi-core future. Intel MIC has 80 cores and it is only the beginning. We need new tools to handle this new level of parallelism. It’s likely that some form of functional, flow-Based, or reactive programming will emerge as the tool of choice in this coming era.

Keyword is 'in association with', I am not talking about multi-core in general.

> I keep hearing this over and over.

Hearing what? That pmap is a drop-in for map giving instant speed gains? That's odd. I've never heard that. Like anything pmap has its tradeoffs.

> poster child for lisp's success

You're conflating "functional programming" with Lisp.

> I think the whole multiple core thing is over blown

That's something that I would probably agree with. However, people tend to focus on that regarding Clojure because it provides more than one model for describing concurrent state changes. People get excited about that I suppose.

> That pmap is a drop-in for map giving instant speed gains? That's odd. I've never heard that.

That was just an example of how programming without state makes it easy to scale it over multiple cores.

> Like anything pmap has its tradeoffs.

No one said anything about pmap being a drop in replacement for map. If pmap didnt have tradeoffs there wouldnt be a 'map' and just pmap.Common Sense. I am not sure why you are even mentioning that. As I said that was just an example of ease of writing multithreaded programs in clojure. Which was one of the main points in the blog post. Did you get a chance to read the blog linked to this post?