The problem being, of course, that you're then writing Java. :)
I still really like Ruby for its expressiveness and malleability, and don't plan to move away from it any time soon, but a lot of that means digging into these libraries, finding problems, and fixing them. I really enjoy that process, but it's rather inefficient for me to be responsible for the performance of every library in my stack.
Ruby has a reputation for being slow, and while it's true that you're not likely to ever reach statically-typed language speeds, it can be pretty decently fast. The danger with tons of abstraction is that a performance hotspot buried three libraries down can turn your otherwise-fast application into a tarpit. If Ruby library developers made performance analysis and optimization a goal alongside "beautiful code" and "DRY", Rails applications across the board would get substantially faster without changes to the underlying VM.
For example, Sprockets uses Pathname heavily. Ruby's stdlib Pathname is extremely robust and extremely slow. This slows down path resolution for every single asset quite a bit. My custom-patched Sprockets does asset resolution and compilation around 43% faster than stock Sprockets. As you can imagine, this has tangible benefits in the speed of my development cycle, and substantially increases my happiness. I opened an issue on the Sprockets project, but it was closed as requiring too-substantial a refactor. Imagine how many developer-hours would be saved if the Sprockets maintainers were to fix that hotspot?
It's worth noting that I don't really like faster_pathname as a solution. It's a cudgel that monkeypatches the stdlib Pathname. A proper solution would be a Pathname subclass that Sprockets uses directly, allowing for customized behavior without potential side-effects in other systems.
you're right on about this stuff. someone once told me "yeah rails is great except the libraries have fugly internals"
but it's trueeee I prefer scripting languages to Java but there are a few of them available on the JVM. To be honest, I think the right balance is in the dynamic-OPTIONALLY-static typed languages.
Java interoperability solves this in a way... I've been taking a look at Dart for similar reasons. I just don't think the answer for me is RoR. Once I learned a Lisp (Clojure) and a lot of javascript I realized a lot of the syntax features I like about Ruby exist in many other places
What RoR really has going for it is the gem community, but if they're hard to trust and come with a slew of other problems...? Tough choices
I'm on the Dart team, and we've heard a lot of positive feedback from Rubyists. Come join us on #dartlang or misc@dartlang.org if you have questions. We'd love to hear what someone thinking of migrating from RoR needs.
Web services that DO use Ruby today are almost always IO bound. For web services that don't require data crunching CPU bound processes, Ruby as a language is hardly the bottleneck.
Don't confuse being IO bound for not having CPU overhead. Being IO bound just means that your app is going to hit a concurrency ceiling due to IO before you hit full saturation on all your cores. It does not mean that a given request can't be faster. Despite the fact that our apps aren't CPU-bound, a few years ago, I patched some performance problems out of Haml and shaved multiple dozens of milliseconds off of each of our requests. That translates into faster page renders, snappier responses, and happier users.
While faster view renders might not improve your theoretical maximum throughput, it will certainly have a positive impact on your users' experience.
I still really like Ruby for its expressiveness and malleability, and don't plan to move away from it any time soon, but a lot of that means digging into these libraries, finding problems, and fixing them. I really enjoy that process, but it's rather inefficient for me to be responsible for the performance of every library in my stack.
Ruby has a reputation for being slow, and while it's true that you're not likely to ever reach statically-typed language speeds, it can be pretty decently fast. The danger with tons of abstraction is that a performance hotspot buried three libraries down can turn your otherwise-fast application into a tarpit. If Ruby library developers made performance analysis and optimization a goal alongside "beautiful code" and "DRY", Rails applications across the board would get substantially faster without changes to the underlying VM.
For example, Sprockets uses Pathname heavily. Ruby's stdlib Pathname is extremely robust and extremely slow. This slows down path resolution for every single asset quite a bit. My custom-patched Sprockets does asset resolution and compilation around 43% faster than stock Sprockets. As you can imagine, this has tangible benefits in the speed of my development cycle, and substantially increases my happiness. I opened an issue on the Sprockets project, but it was closed as requiring too-substantial a refactor. Imagine how many developer-hours would be saved if the Sprockets maintainers were to fix that hotspot?