Hacker News Reader

Comment by tptacek | Hacker News Reader

It's also the case that headcount is far more expensive than servers.

A really talented sysadmin with good tools may be able to manage 100 servers; a great developer can optimize your algorithms to get an order-of-magnitude reduction in the number of servers you need.

Eventually, more servers == more headcount.

No other implication about Scala intended (Alex is very credible), but optimizing for lower hardware footprint at the expense of your hiring pool (by choosing a very niche language) seems like a bad trade.

Won't every new developer who works on this codebase lose a week to two weeks becoming facile in Scala? Assume a 6 person dev team, and a conservative fully loaded $180k for a valley dev, and that's $43,000 out the window.

Once upon a time, people made the same comments about Ruby and Rails: "it's a fringe language", "the tools are immature", "you shouldn't use it because you can't find Ruby coders", etc., etc.

I find it honestly hilarious to hear it suggested that one of the early high-volume Rails shops should stick with "safe" language choices because they won't be able to hire enough developers to work with a new language.

I've read through the sources to Kestrel, and found them quite easy to grok. If anything, most real-world Scala code seems to be essentially very clean Java, with much of the syntactic cruft (redundant type declarations, inner classes, 'public static final' declarations, etc.) removed. Any experienced, effective developer is going to spend far more time getting to know your in-house APIs and coding style than they are the language.

Again: not an anti-Scala person, just turning the economics of this around in my head. That said:

Ruby is our house language. We've never hired anyone that came in the door knowing Ruby. We have a very high bar for hiring (typical first project: "write a programmable symbolic debugger for closed-source binaries on platform Y"). It takes people at least a week to become facile with Ruby --- a famously easy language to learn. Reading isn't writing.

If you have a house style, easily figure another week to pick up the right idioms, so that your code survives in the repository and isn't just refactored out.

How big is the codebase for twitter? Are you limited by devs or production resources?

You can also swap in Java components when you need to so, depending on the architecture, you may only need a small Scala team. Java devs are everywhere. You also win by acquiring easy access to Java libraries.

Not saying Scala is the right choice... but there are big advantages besides "Scala is lighter than Ruby" -- and Scala is a lot lighter.

But their move to Scala meant the Fail Whale went away and their investors were happy enough to sink many more millions into the company. Would it be possible to run a high-volume messaging system in Ruby? Perhaps. But why fuck around when the people bankrolling your company are getting angry?

Hey you know what? Not making a case for Ruby here. Just picking one very small part of Alex's argument and critiquing it.

It might cut down on the volumes of resumes, but once culled down to actual potentials, I think the effect of the "niche language" is minimal. I spend my time hopping between a bunch of languages and I'm equally mediocre in all of them, but my friend who does the same is amazing in whatever language is thrown at him. I have yet to meet a really excellent programmer that can only program in one language (they might not be equally proficient in all of them).

When hiring for the small percentage of excellent programmers, I don't see language as a barrier. Sure, there will be spin up time, but you'll have that regardless. No one is experienced with every library, framework, or configuration. Adding in a new syntax might compound the issue, but I think that there is the definite potential for long-term productivity gains once the team is up to speed.

On the other hand, using an elegant, smooth, well-designed language like Scala is a perk that helps you hire excellent devs for less money. Plus, if you want to transition a bunch of experienced Ruby devs to a faster language without losing most of them, you'd better not pick Java or C++.

That's kind of a straw-man argument, isn't it? Nobody is moving from high-level languages back to C or even Java. The talk here is of moving from "early adopter" to "innovator" on the adoption curve. And I'm just making the point that when you do that, you necessarily either contract your candidate pool, or add ramp-up overhead to new hires.

I'm defending their choice to move to Scala (a "niche" language) after running into performance problems with Ruby. I don't think it's a straw man to mention Java and C++ as representative of the non-niche languages that perform significantly better than Ruby. There are plenty of faster language platforms they can move to, but which ones offer a powerful and elegant language? As far as I know, you either pick a "niche" language that few developers know or you pick an old and clunky language like Java or C++. In this case, you have to weigh the ability to hire new people, which would be better for the more popular languages, against the ability to retain your existing Ruby developers, which is better with an elegant, powerful language.

Still, I worry that despite Ruby's niceness, a lot of time is spent developing around it's issues. Whenever I read about deploying Ruby, it just sounds scary. Memory munching Mongrels that have to be restarted on a regular basis? It sounds like a science in itself, whereas tomcat just runs and runs and runs. Less headaches == less headcount.

If you know and like Tomcat, may I suggest you have a look at JRuby deployment for Rails apps? With recent versions of jruby-rack and the warbler gem, it's as simple as listing your dependencies in a config file, and then running 'rake war' from the top level of a Rails app to get a shiny new WAR file ready to drop into your Tomcat deployment directory.

Thankfully these issues have been completely solved by passenger/mod_rails. Deploying Rails apps is now trivial and stability (at least outside of extreme loads) isn't an issue.

Reply on news.ycombinator.com