[ssmoot]

I'd suggest Play Framework and abandoning the idea of O/R Mapping entirely.

Once you grok pattern matching you'll never want to see another Ruby case statement again. Once you compose a pipeline of functions you'll find Ruby Procs a pale shadow of true functions. There's really no such thing as functional Ruby.

You'll end up with more maintainable code, a lower LoC count, easier testing, more mature libraries, and that's just the tip of the iceberg.

Un uncached Play Framework app will probably outperform a highly tuned Rails app out of the box, even with hundreds of person-hours spent in tuning the Ruby app.

Which leaves you more time to work on actual features.

And then you have Akka. Which is a whole other paradigm to master (but with it's own rewards).

And then you have deployment. Which is a huge breath of fresh air.

Sure, you'll miss some few things in Rails. Like Inflection. Add a dependency for one of the ported versions (like: https://github.com/backchatio/scala-inflector. It's just a single file).

The learning curve isn't the smoothest (though API docs for Java/Scala libs in general and the Play Framework guide is far more complete than anything I ever experienced in Ruby-land). But the rewards.

Come to the dark side. :-)

[vinceguidry]

> I'd suggest Play Framework and abandoning the idea of O/R Mapping entirely.

Then I'd have to learn Scala. I do not want to have to learn an entirely new stack. It took years for me to learn Ruby's eccentricities. Sure it would take me less time to learn Scala, but I already know Ruby. You seem like quite the masochist, spending years in one ecosystem trying to build something, then burning it all to the ground and starting all over. Just looks like so. much. effort.

> you'll never want to see another Ruby case statement again

I never write case statements in Ruby. What I do when I find myself needing a case statement is to go looking for the missing class. I'm missing a domain element and OO programming to me is all about clarifying a domain.

> Once you compose a pipeline of functions you'll find Ruby Procs a pale shadow of true functions.

I pipeline all the time in Ruby. A lot of times I'll wrap a data pipeline in a class so I can encapsulate the logic and manage it better. When you wrap a pipeline in a class, you can do things like add immutability to the instance variables. Sure, it's not true functional, but I don't want true functional.

> You'll end up with more maintainable code, a lower LoC count, easier testing, more mature libraries, and that's just the tip of the iceberg.

Let's take these in turn.

> more maintainable code

I love maintaining my code. I fail to see how learning a new stack could actually improve on this for me.

> lower LoC count

Mostly aids in maintainability. Again not at the top of the list of things to improve.

> easier testing

I've changed my approach to testing over the years. Again, this is not anywhere close to the top of the priority list.

> More mature libraries

Again, this is something I've fixed by changing my approach to the problem. Whenever I introduce a gem, I put an interfacing class between the rest of the app and the gem. That way it's easy to swap out if it becomes a problem.

> And then you have deployment.

Deployment sucks in Ruby, not gonna lie. But again, problems are indicators of overcomplication and I've tuned my workflow to drive more simplicity over time. I know Capistrano very well, seeing it evolve over time has given me a keen eye for how to keep it manageable.

On the whole, I like the idea of functional programming and am not opposed to coding in a functional style once in awhile. HtDP changed the way I thought about programming, though I eventually switched back over to OOP. I strongly disagree that there's any kind of magic to functional. Everything in programming involves tradeoffs, and OOP better fits my mind than functional does. I look at pure functional as math-heavy and harder to grok. I want stateful objects, because humans think in terms of objects and not data pipelines.

> The learning curve isn't the smoothest

That one issue outweighs all the purported benefits of all the others. I would much rather spend my time thinking about domains than learning new tricks.

[ssmoot]

There's nothing I love more than a long thread of point-by-point rebuttals, but I think I'll leave this one alone for once. ;-)

If you like what you're doing, more power to you. I picked up Ruby because I thought it showed promise as a good scripting language and web development tool (this was pre-Rails) at a time c# didn't really excel at either.

> You seem like quite the masochist

Maybe. DM was created to solve a problem. I didn't burn anything down. I just walked away. The best time to do the right thing is yesterday. The next best time is now.

After 8+ years, I realized I'd spent much of it trying to work around limitations in Ruby. It was just time to open myself up to the idea that there is more to programming than what I knew.