Hacker News Reader

Comment by charlesju | Hacker News Reader

Having 2 RoR products in the time it takes you to build 1 Scala product is the true competitive advantage.

Please read the original article. Nowhere in it (or the original talk) does Alex advocate using Scala instead of Rails for the things that Rails does well -- namely, interactive web page rendering.

Within that niche, Rails does a fine job. For infrastructure and middleware code, however, Rails has little to offer other than the Ruby language, which has serious issues when applied to time + memory-intensive problem domains.

I'm a huge fan of Ruby, and a (perhaps somewhat begrudging) user of Rails, but that doesn't mean I think they're the right solution to every problem.

"The trouble, he insisted, is that the so-called Web 2.0 languages aren't always as efficient as they need to be, especially in an economic environment threatening to bring Web 2.0 to its knees."

I'm saying that is false, over-optimization is what brings startups to their knees.

Why is it "over-optimization" to use language with a genuinely well-implemented runtime?

If there's anything I've noticed over the years when building websites, it's that customers care a ton about speed. I'd argue that it's the most important feature, followed by design. The more responsive your interface, the better. Now, you shouldn't sacrifice key features to speed things up, and you shouldn't optimize your code from the get-go, but your product had better be fast.

Google won because of good search results, but I remember that the first thing about the search engine that impressed me when I first tried it in 2000 was its responsiveness.

Speed is very important. However: how much time does server spend running your Ruby code? I think I saw somewhere it is about 5% of the request time. There is DB, network latency, all the client side cruft (twitter did not get even assets caching right yet). Article says they are leaving Ruby in place for the front end, so most likely they do understand where bottleneck is, and where it has nothing to do with a language.

I just hope that other won't jump to porting their code without understanding the reasons. It should be pretty embarrassing to spend six month porting the codebase just to find out that reducing time server spends in your app code from 5% to 1% did not impact the overall speed of your site.

It would be interesting to see more details about those queue processing problems they have though.

But we've already been over this: It's not Ruby, it's Rails that's slow.

http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

Scala is 900x faster than Ruby for some workloads. Ruby is not a fast language. It works for web stuff because every language waits for IO as quickly as the others.

But Twitter isn't a normal website and Ruby was the reason why it kept failing. That doesn't mean your website will fail because of Ruby, but Twitter had too much background messaging work for Ruby to keep up with. The fact that simply replacing the code with Scala made huge improvements should demonstrate that fact. They didn't change what was being done, just what language was doing it.

/agree the bottleneck for any website is ALWAYS the database, never the language. If you have requests that are bottlenecking at the language, nothing is going to solve that.

Reply on news.ycombinator.com