For Thursday’s last talk at Windy City Rails, Sean Griffin (the guy to talk to about the problem you ran into with Rails 4.2 beta, by the way) discussed “The Functional Web: How Functional Programming Concepts Could Improve Rails.” The talk centered mainly on the lack of concurrency in Rails. It’s a problem that I’m sure has produced or would produce an interesting discussion over drinks with Brian Shirai, our ambassador at the conference for Rubinius X, which, ICYMI, is trying to fix that (though in a decidedly object-oriented way).

Maybe we didn’t get all the jokes in the talk (sorry Sean), but it still left my interest piqued: Sean introduced to me a discussion in Ruby to which I had had little exposure before. TO write effectively about it, I had to look some stuff up. So, I figured I’d pass those resources on to you.

Not sure what we’re talking about? Sean defined concurrency thusly:

concurrency – doing multiple things on a computer simultaneously, preferably on multiple cores.

And Rails doesn’t allow for concurrency except in IO. In fact, Ruby itself can’t run concurrently, for the most part.

So how can we bring concurrency to rails—and specifically to out controllers? Sean approached the problem in his talk from the vantage point of the Scala programming language. Talk to him more about his ideas re: scala on rails. Can’t find him? Tweet @sgrif. Or look for “the guy in the hat.”

But if you want the conversation to get deep, you might want to brush up: 

Here’s Merbists’s Blog, which explains Ruby concurrency in depth (check out the related articles at the bottom: they’re just as helpful as the linked one) 

Heroku also talks about this on their blog, specifically about Rails

Another take on using functional programming concepts in your Rails codebase

If you’re curious what full-on functional programing might look like in a Rails-y environment, have a peek at Skinny.    Also, Scala Play.