I’m going to bite and take issue with this point that Josh makes:
I think this is the most likely threat to the Rails surplus, that C# or Scala or something can do a good enough job that people can double their productivity with far less of a change in mindset or tools, and eventually no one will care about the ten times (or whatever) productivity of Rails. “Good enough is good enough.”
Now I’ve not used C# much in anger (I have however seen some of the cool ideas pulled in from F#) so won’t comment on it, but I’ve now developed one large Rails app (multi-year, multi-person), one small Rails app and been peripherally involved in one medium & one small Scala projects (in addition to three Scala OSS projects), preceded by about 10 years of Java/C++/PHP projects.
So, I feel quite qualified to offer an opinion on the contention that Scala’s doubling of productivity is “good enough”. Too summarise this post early, this is just plain wrong , the productivity boost that is, not the “good enough” bit. Learning functional techniques will not only make you more productive, but at worst they’ll make you a better “Rails programmer”.
Note that I’m not going to address the “Rails vs. Scala” debate, which would be better rephrased as “Ruby vs. Scala”, or “Rails vs. Lift or a hypothetical Scala web app framework”.
I’m quite happy for people to claim the now standard “10x” productivity boost for new Rails apps, having been through a couple now, I can see how it gets you up and running quickly, mainly by taking a bunch of decision points away from you (that you’d have to make in a Java project for example, what O/R tool, what directories do I need, etc.) and how it simplifies a lot of the drudgery found in most web projects. Throw in some clunky higher order functions for good measure and you’re away!
Actually, I’m not entirely happy with accepting this, I’ve found that in my experience you save about 25% of total development time for small projects, but the curve flattens out the longer the project goes on (say, after a few months), if you add more people, if the project is complex or it’s not a webapp. If any of these get large, you loose the advantage of Rails. Ruby’s lack of a static type system also leads to issues, however I don’t want to address these in this post.
So I have no real problem with Rails for simple web projects; Rails is optimised for the general case, and when you stick to what it’s good for Rails is fine (ignoring the thorny issues of side-effects & composability). What I do have a problem with is claims that developers would want to settle for Scala, or, any (pure or not) functional language.
I’m not a functional programming guru, however I know enough to be dangerous and I like to improve the way I develop software. There are many compelling reasons why people love functional languages. They are succinct, elegant and composable. I’ve heard “functional programmers”  make claims that they can employ high-level abstractions (with funky names like monad & functor) to get massive increases in productivity (usually one to two orders of magnitude). What’s more, they can back up these claims also!
I can only speak first hand about the tools that I’ve used, but I can certainly see how people can make these claims. In what little Scala I’ve written, I’ve seen how you can drastically reduce the size of your code, increase its readability and improve your ability to reason about what’s going on . And this has helped me a lot in my current Rails project!
I’ll say it in different terms, knowing functional programming techniques means you can write Rails apps faster (yes, better than 10x!) . I’ve experienced this first hand on my current project. I’ve written code that would have taken me half a day in Java in 10 minutes, made possibly by only a miniscule knowledge of functional techniques (e.g. map & fold). There’s another post on countering claims that no-one ever uses these abstractions… I’ve used two folds and a map already this morning.
Also, once you learn the basics, with functional languages you also get a better handle on what it is you are actually doing as the language of the problem is the language you’re coding in. You stop thinking in terms of the machine, and more in terms of the problem you’re trying to solve. For example consider this piece of code from Furnace:
What does it do? Well it removes the header from a stream of bytes, filters out newlines and takes the first 40 bytes. Does the code look similar to the way I’ve described it?
When I first tried to write this code, I thought about the underlying stream of bytes, pulling them off one by one, what about buffering, what happens if I read too many and need to skip back, etc. My thoughts had been warped by years of imperative thinking. When I discussed this problem in the office, I realised that this can be represented simply, if I simply though about what it was I wanted to do, and the code came very easily after that .
Of course there are tradeoffs here, and learning function techniques is mind-bending (in a good way), you’ll also realise how little you actually know. By using a language like Scala you get to have your cake (e.g. great APIs, type inferencing, DSLs, etc.) and eat it too (static typing). You also get great productivity improvements. Am I willing to put a number on it, no, I don’t have enough experience yet, but I can see it has the potential to be large.
This has been a bit of a rambling post, but my central premise is these two things; 1) Using functional techniques will let you be more productive in the general case (i.e. not just web apps) than Rails makes you for writing web apps; and 2) learning functional techniques will make you a better “Rails programmer”.
 To be fair, Josh is probably just throwing out the names of the latest languages that are causing a buzz, so Scala gets lumped into that. Still, this doesn’t make the statement true.
 Functional programmers usually don’t like to use this term, but I’ll use it here for quick categorisation.
 You also get other nice things like improved testability, increased maintainability, flexibility, etc.
 I have come up against some of the barriers to making things even easier, for example using APIs that rely on side-effects and are not referentially transparent breaks your ability to compose functions, which at its least is really annoying, and its at worst has a huge impact on a project.
 This code is not without its faults. It builds the stack, but is composable. A solution using iterators won’t build the stack and is more efficient, but is not composable, leading to code that is harder to reason about.