Twitter survives election after Ruby-to-JVM move

http://www.theregister.co.uk/2012/11/08/twitter_epic_traffic_saved_by_java/

by tawman • 14 years ago

131 167 14 years ago

theregister.co.uk

eta_carinae• 14 years ago

The rumors of Java's death are, indeed, greatly exaggerated.

esusatyo• 14 years ago

They used Scala, not Java, on JVM.

trimbo• 14 years ago

They use both.

"Last week, we launched a replacement for our Ruby-on-Rails front-end: a Java server we call Blender. We are pleased to announce that this change has produced a 3x drop in search latencies and will enable us to rapidly iterate on search features in the coming months."

http://engineering.twitter.com/2011/04/twitter-search-is-now...

mercurial5• 14 years ago

Actually, TFA states they use a mix of both.

46Bit2• 14 years ago

Java isn't sexy any more. You use Java because your problems are, and so it doesn't matter to anyone.

elchief2• 14 years ago

JVM is a wonderful thing.

camus6• 14 years ago

Github and the thousands of Rails powered websites have no problem scaling, so i'm pretty sure neither Ruby nor Rails are a problem.

thebluesky9• 14 years ago

With enough hardware you can make virtually anything scale, for a price...

jacques_chester2• 14 years ago

Github is an easier problem: generate pages.

Twitter has to deal with very high fanout and low cacheability.

elchief2• 14 years ago

500 million users is more a little more demanding than 2 million users.

Cowen• 14 years ago

> None of this will be welcome news to the army of fanatical Ruby developers who believe the language's syntax, its high developer productivity, and its overall philosophy far outweigh any performance disadvantage it might have compared to other languages.

I'm a relative newbie to the Ruby world, but as best I can tell, the Ruby and Rails communities both accepted long ago that they weren't made for Twitter levels of traffic.

Fact is, almost no one has Twitter levels of traffic besides Twitter. That's why Ruby and Rails are still so popular, because for ~99% of performance needs, they're more than capable and also extremely pleasant to work with.

robryan• 14 years ago

Yeah, that line feels like lazy reporting to me. Any involvement at any in the Ruby community over the past few years and they would know that very few Ruby developers are concerned about the performance issues past a certain scale.

Seems like a no brainer that something that is a lot more strict and static will outperform something that has to deal with many more possibilities at runtime.

mercurial5• 14 years ago

> Yeah, that line feels like lazy reporting to me.

Now, now, it's The Register. The tabloid style is part of its identity.

erichocean2• 14 years ago

Would have been nice if the title was "Twitter survives election after Ruby-to-Scala move", since that's what actually happened.

(They do use a bit of regular Java, but the majority of the core code is Scala, and it's Scala that should be getting the top line credit here, not Java.)

taligent• 14 years ago

No. It is the JVM that should be getting the credit.

otibom• 14 years ago

Magnetised needles and steady hands.

erichocean2• 14 years ago

If that were the case, they could have just run JRuby and avoided rewriting a bunch of code.

The truth is, Scala is actually helpful with the architecture they came up with AND its great that it runs on the JVM.

kevinconroy2• 14 years ago

The novice programmer says: "My language is better than yours."

The wise programmer says: "Use the right tool for the job."

Please HN, we're wiser than trending stories would suggest.

verroq• 14 years ago

The wise programmer rewrites his stack in another language to scale right?

pirateking2• 14 years ago

The wise programmer does not write programs. Therefore, the wise programmer does not exist.

philwelch3• 14 years ago

If your software is Twitter, then you're constantly rewriting the stack anyway just to keep up, and switching to different languages, frameworks, technologies, and tools component-by-component is often the best way to do that.

pg• 14 years ago

Do you think it's impossible for one language to be better than another?

If so, it's impossible for a language designer to do a good job, because it's impossible to improve a programming language.

fizx• 14 years ago

It seems to me that he is arguing that languages do not have a total ordering. As such, novices will argue that a language is strictly better than another, when a broader perspective will reveal that this is only true for some use cases.

The "no free lunch" theorem would indicate to me that there is no ultimate language, merely languages that are better for common (to you) use cases.

nathancahill• 14 years ago

That's not what he's saying at all! The "wise programmer" uses the right tool for the job because it IS a better tool for the job. In the same way, we'll continue to see an increase of programming languages, as opposed to a consolidation, as computing advances and languages improve.

kayz• 14 years ago

I can't speak for him/her but it seems to me the point is that computer languages, while being all-purpose, are products of countless conscious design decisions of their creators. And thus by the nature of design, tradeoffs are inevitable.

So I think the (even just sometimes) discussion of "good language" should be limited to the context of purpose and goal of the said language, which is similar to "choosing the right language for the task".

pirateking2• 14 years ago

I do not think the continuum of language can be mapped along one dimension when considering individuals. Constant development of languages, patterns, and idioms are global manifestations of individual frustrations.

Ideally, every person would have their own programming language (or culture), grown from their own personal experiences and desires. In that case, a qualifier for a good language is one that most easily allows expression of new languages or cultures at the individual level.

For a language designer, this could be an impossible problem due to the unique learning models of each individual. Their best hope may be in attracting those whose mental models have some overlap with their own.

zorbo• 14 years ago

> because it's impossible to improve a programming language

Well, since "improve" is a relative and a matter of taste, it is impossible to improve a language, isn't it? Make it run faster, and it will either take up more memory or be slower to develop with. Make it faster to develop with, and it will run slower or have some other tradeoff.

Hence, "use the right tool for the job". And when your focus shifts from "quickly building a product" or "quickly adding new features" to "rock-solid stable and fast", then you need to switch tools. Simple as that.

kevinconroy2• 14 years ago

If all you have is a hammer...

I think all languages have strengths and weaknesses that matter based on the context.

For example, I hate manually managing memory in C/C++. Java, Ruby, etc automate all of that for you, but it comes at a cost of using a lot more memory. That's not a big concern for many applications, but if you're doing embedded software or real-time systems it can be a deal breaker.

So in this example, is C++ better or worse than Java? The answer is that it depends what problem you're trying to solve, what environment you're running in, and what resources you have available on your development team. Personal preference matters too in terms of programmer satisfaction, but just because you like one language's constructs more than another doesn't mean it's well suited to every problem space.

As to the original article, I think it's great to learn about how different companies change their software stack, but not because "w00t Twitter hates Ruby - Java rocks"; rather it's interesting to see how business context changes over time and the implications that has on the technology. Seeing how other businesses have dealt with these hurdles can help you keep an eye out for them in your own business. I just wish that this was the lens that it was written in rather than "OMG - Ruby = Fail Whale."

If you're a language designer then it's good to hear about the complaints and preferences of programmers so that you can design a better language (and thus a better tool). And like any tool, there will be times when it's better to use one language rather than another.

pyrotechnick7• 14 years ago

This move marks the beginning of the end of a four year long effort for Twitter to rid themselves of Ruby.

History will remember the entire Ruby industry as a series of compounding failures.

The de facto formalisation and specifications.

The black-box behaviour of core development.

The broken-linked, un-versioned docs.

The rampant cargo-cult mentality.

The arcane exceptions.

The meta-frameworks.

Gem hell.

1.9/2.0

Rails.

SoftwareMaven• 14 years ago

I'm not a Ruby developer, but I still can't help thinking, "WTF".

No technology stack is perfect, but I've yet to meet a stack that was pure evil. There may be some cargo-cult personalities in the Ruby community, but, if there is, it's only because there is value in it.

An infinitesimal number of sites have to deal with Twitter's scale problems. The rest can work on getting crap done instead of worrying about Maseratti problems.

knowtheory5• 14 years ago

Allow me to be withering in my criticism of GP.

Cargo-culting is what you accuse others of when they are learning and you do not like them.

The appropriate way to deal with newbies who do not fully understand the consequences of the decisions they have made (perhaps even while they are advocating others join them), is to explain their rhetorical and technological shortcomings in a way that others can learn from. Accusing someone of "cargo-culting" is just unhelpful character assassination.

Also, weak-sauce.

pyrotechnick7• 14 years ago

argumentum ad populum

thebluesky9• 14 years ago

> No technology stack is perfect, but I've yet to meet a stack that was pure evil.

As someone who has seen Ruby cause major problems I'd have to say it's not too far off "pure evil"

colinbartlett• 14 years ago

I call bullshit. This doesn't spell the end of anything. Ruby isn't the right tool for the job and hasn't been at Twitter for a while. This is old news. Ruby has a place in a lot of other scenarios.

foz• 14 years ago

> History will remember the entire Ruby industry as a series of compounding failures.

This is a bit dramatic. Despite its faults, the language and community around it have been quite a success story. It's had a huge and positive influence on the web development world.

knowtheory5• 14 years ago

It's also worth rebutting douchebag trolling with the Ruby community's actual merits.

The Ruby community, really really cares about developer tooling and teaching others. Ruby is also one of the nice places where object oriented programming touches metaprogramming.

Don't forget that a lot of sysadmin work is done in Ruby now. Both Puppet and Chef are written in Ruby, and that Github and Heroku both came up out of the Ruby community.

wmil• 14 years ago

> Gem hell.

Is this really a problem? Every package/dependency manager seems to blow up on occasion. Gems haven't given me the problems that I've had with Pip/CPAN/Autoconf.

pyrotechnick7• 14 years ago

Hell: not really a problem.

knowtheory5• 14 years ago

It's enough of a problem that bundler was written. Of course Bundler sorts the problem out pretty well so... Hell averted :P

yxhuvud• 14 years ago

The only Gem hell I know of is when using distro packaged gems. They tend to do weird crap like changing dependencies or backport fixes instead of packaging the new version.

There are things more funny to do than solve bugs introduced by a backported patch.

philwelch3• 14 years ago

Obvious flame bait. Please don't post this garbage on HN.

pyrotechnick7• 14 years ago

http://news.ycombinator.com/threads?id=philwelch

keymone2• 14 years ago

sir, troll more please

timothya• 14 years ago

It's interesting that when it comes time to scale to serve enormous loads, you have to be willing to change fundamental parts of your stack which you've made a huge investment in. Ruby holds up well enough on the majority of the sites that use it, but when you have traffic the size that Twitter does, it's just not good enough. And it turns out that Java provides a nice tradeoff with high performance and high-level code.

It's also interesting to see different companies approach this problem differently - Facebook famously recreated a way to run their PHP source code (by compiling it to C and then running it natively) instead of actually rewriting the source to a different language. I wonder if something similar would have been possible for Twitter, or if they weren't happy with how their existing code was structured in the first place which may have made the rewrite more attractive.

adamsmith• 14 years ago

Facebook also has many more features, which probably means more code, which probably means larger switching costs. Take anything: photos, privacy logic, news feed, etc., and Facebook has the more sophisticated feature set.

jshen3• 14 years ago

It's not primarily about the size of traffic, but the ability or inability to cache. At work we serve a ton of traffic with MRI ruby and 3 small VMs. Most requests are served by varnish and never hit the ruby stack. Most people do a terrible job at caching (edit: I'm not saying that twitter is bad at caching).

kayoone• 14 years ago

Twitter is hugely write intensive and needs realtime data, so their caching needs are probably vastly different from yours.

bryanlarsen• 14 years ago

Agreed. I've got a page that takes 20 seconds to render on a dedicated fast machine. I could spend some time optimizing it, but even then it would still be slow. However, it's cacheable so I can fix performance problems with a simple post-deploy script. We can't do that for every page, but it's awesome when we can.

firlefans• 14 years ago

"Python is fast enough for our site and allows us to produce maintainable features in record times, with a minimum of developers," said Cuong Do, Software Architect, YouTube.com.

There are many dynamic user driven sites which have scaled well (far less downtime than Twitter) without switching to static compilation.

bad_user2• 14 years ago

You can argue that YouTube is less dynamic than Twitter. When a user posts a message on Twitter, that message has to be pushed to all the users that follow that user and so every user has a personalized stream of incoming tweets that has to be updated, not in realtime, but with small latency nonetheless.

Also, Twitter doesn't have Google's infrastructure.

In regards to "static compilation", that's not the important bit, but rather the performance of the virtual machine. The JVM, at its core, is not working with static types. The bytecode itself is free of static types, except for when you want to invoke a method, in which case you need a concrete name for the type for which you invoke that method ... this is because the actual method that gets called is not known, being dispatched based on "this", so you need some kind of lookup strategy and therefore the conventions that Java uses for that lookup are hardcoded in the bytecode. However, invokeDynamic from JDK 7 allows the developer to override that lookup strategy, allowing one complete dynamic freedom at the bytecode level, with good performance characteristics.

The real issue is the JVM versus the reference implementations of Ruby/Python. The JVM is the most advanced mainstream VM (for server-side loads at least).

Unfortunately for Facebook, they didn't have a Charles Oliver Nutter to implement a kickass PHP implementation on top of the JVM - not that it's something feasible, because PHP as a language depends a lot on a multitude of C-based extensions. The more pure a language is (in common usage), the easier it is to port to other platforms. Alternative Python implementations (read Jython, IronPython) have failed because if you want to port Python, you also have to port popular libraries such as NumPy. Which is why the PyPy project is allocating good resources towards that, because otherwise nobody would use it.

vidarh3• 14 years ago

No, you don't need to change fundamental parts. You need to get the architecture right. Then you need to determine whether the potential cost savings of switching languages are worth it for you. If things start falling over when you scale, it's an architecture problem, not a language problem.

Why do I say that? Because in Twitters case, handling tweets is a "trivial" problem to parallelise, and the potential savings of switching language will be a rounding error in terms of scaling their system compared to getting the architecture right.

(To scale Twitter: Make trees. Split the following list into suitably wide trees, and your problem has now been reduced to an efficient hierarchical data store + efficiently routing messages. Both are well understood, easy to scale "solved" problems)

randall• 14 years ago

Would love to see someone at twitter refute this... seems too simple to be correct. :)

rjzzleep• 14 years ago

it's funny that this is even an issue anymore. at the time where twitter was started, the ruby vm has huge issues, and you couldn't even do evented io.

what I find even funnier is that people just throw in play and grails without a little of experience in rails. The eco system is entirely different:

- you can use java and therefore java libraries(yes you could do the same in jruby, but nvm) - bundles/gems are an order of magnitude better than classical java dependency hell. - need something in rails? add a gem. need something in grails? search throw the outdated plugins, search for missing documentation(just take a look at stackoverflow). in general -> write it yourself or pay a consultant to do it. - have a question? fight with incomplete documentation.

on top of that grails is just a stack on top of the spring mvc.

what about play? i like play more than I like grails tbh, because it doesn't want to be the rails of java. yes people compare it to one another, but that's just the familiarity effect.

now, where's the computationally intensive stuff? nowhere to be found. it's a web api. where's the computationally intensive stuff in twitter? I don't know, but chances are theres a native extension for that nowadays.

There actually was a time when you simply could not build a scalable system in ruby without too many hoops, but that's no longer the case. Yes the GIL is bad, but keep in mind that things like ruby fibers didn't even exist at the time.

irahul6• 14 years ago

> i like play more than I like grails tbh, because it doesn't want to be the rails of java. yes people compare it to one another, but that's just the familiarity effect.

My memory might be playing tricks on me, but I remember play developers talking about rails being a huge influence.

If Play isn't rails for Java, how else one does a Rails for Java? The "familiarity effect" is there because Play is modeled after Rails.

> now, where's the computationally intensive stuff? nowhere to be found. it's a web api. where's the computationally intensive stuff in twitter? I don't know, but chances are theres a native extension for that nowadays.

Search, for one is computationally intensive. I am pretty sure there are more which the outside world doesn't know about.

> There actually was a time when you simply could not build a scalable system in ruby without too many hoops,

What scale are we talking about? At Twitter scale, ruby or anything else has to jump hoops. For example, network load from users coming online and offline on FB chat will break out of box solutions.

gary4gar2• 14 years ago

Twitter's better performance is because of a better architecture than Java language. Further, the performance is from JVM, so you can use any of the JVM language including JRuby to get similar effects.

This articles seems more like link-bait to me.

jrockway5• 14 years ago

I agree. I think I could write a scalable Twitter in mostly Ruby. And I've never written a line of Ruby in my life.

scribu2• 14 years ago

Have you worked on other sites with a similar scale to Twitter? If not, how would you know?

logn• 14 years ago

I don't think so. Java outperforms JRuby, probably because of typing. See: http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

extension• 14 years ago

Java probably outperforms JRuby primarily because the JVM was designed and tuned to run Java.

But in any case, if Twitter's architecture is truly scalable then any intrinsic slowness of the language shouldn't be a big problem, because they can just toss more hardware in to compensate. What is a problem is a buggy VM that leaks memory. To run thousands of instances in a heavily instrumented way, the VM must be stable and predictable.

igouy3• 14 years ago

Probably because there are better Ruby programs to be written for those tasks :-)

cpt1138• 14 years ago

Ive heard that Java is DSL for turning large blocks of XML into stack traces. But it does it fast and reliably.

anonymous• 14 years ago

Hah. I'd put it more like: Java is a platform for building frameworks for implementing interpreters for XML-based DSLs.

malandrew• 14 years ago

While I can agree that scala/java/jvm deserve some credit for this (typing, concurrency support), I think stories like this do a disservice in that they underestimate the importance of building a system a second time with all the lessons learned the first time around.

This is not unlike those stories where a developer writes a trivial program in a new language that is similar to a trivial program they wrote in another language 1+ years prior and compare the results. "I wrote program foo in 30 lines of code in language X, which is much better than the 120 lines of code it took me in language Y two years ago". It's natural for a developer to write a shorter program two years later since they have 2 more years under their belt. In fact I'd expect the same program to be much better two years later even if written in the same language.

46Bit2• 14 years ago

Very true. Twitter may have had a lot of scaling trouble, but that didn't necessarily mean moving everything onto the JVM was necessary to 'make it scale'. It was just sensible to pick a language that would prevent problems in future.

ww5202• 14 years ago

But if the second design is the better design theory has any impact, Twitter would have done better to build the second design with Ruby.

nnq2• 14 years ago

...I never get it why scaling is seen as such a "hot" problem and everybody seems inclined to make language and technology choices based on it ...I bet Twitter could have scaled well keeping Ruby and rewriting performance critical parts in C and maybe keep tweaking and tuning the Ruby interpreter, much along the way the Youtube team did with Python and C and now some Go I hear...

I think their decision was more influenced by the experience of their team of programmers or by employable talent pool - they went the JVM|Java|Scala route because they had people with experience in high level languages and the JVM. If they happened to start with a team with "C hackers" background they would've gone the Ruby|C way and it would've worked as well.

...I think almost any language and technology can (be made to) scale, even to Twitter scale, at least if it's open-source and you have people with the required technology to hack around the internals and recode performance critical parts in lower level languages (basically C, C++ or Go nowadays)

willvarfar• 14 years ago

Did you skip the bit in the article where they mentioned the faster Ruby VM they built, before moving to JVM?

http://engineering.twitter.com/2011/03/building-faster-ruby-...

nnq2• 14 years ago

no, I didn't skip it, and I can only guess that either they considered they wasted to many resources for such a "small" performance gain or didn't have people with enough skill in the right areas to keep going this direction. But no, I don't know all the details and steps of Twitter's switch and my experience is in the Python ecosystem but I think lots of things are similar...

SiVal• 14 years ago

What this says to me, a non-RoR user, is that it's harder to build websites with Java than with RoR, but if you pass a certain (very unusual) level of traffic, you'll wish you'd made the extra effort; otherwise, you'll be glad you didn't. (Extra effort isn't free.)

Fine, but what I wish I understood was why RoR is so popular to begin with. The claim is always that Rails is so wonderful that it's worth learning Ruby just to be able to build web apps with Rails. Well, if so, then why isn't there a sequel to RoR: Python on Rails? "The benefit people care most about (Rails, not Ruby) using the language you already know (Python)." Since Python, Perl, and Ruby are so similar except in syntax, and people love the Rails part more than the Ruby part, and so many more people know and love Python, and new Python web app frameworks appear all the time...why isn't one of them Python on Rails after years of Pythonistas being forced to abandon Python and learn Ruby just to be able to use Rails?

Is there some significant difference between Python and Ruby that explains this? What makes Rails so attractive and why isn't the same thing done with Python?

hayksaakian• 14 years ago

Its called Django.

knowtheory5• 14 years ago

Python has a roughly equivalent MVC web framework called Django.

Ruby and Python as languages are not radically different in kind, but their respective developer communities have had different focuses, and as a consequence the library of tools are not identical.

Ruby on Rails became popular because people were dissatisfied with the way that web development was being done, and DHH is very good at marketing/propaganda. Ruby on Rails has had a substantive effect on the way that web development is done, and there have been numerous attempts in other languages (that didn't already have a framework like Django) to recreate the things that Ruby programmers enjoy with Rails (CakePHP and Grails come to mind immediately).

bryanh• 14 years ago

This is spot on.

To elaborate a bit, Rails tended to have a lot more generated code (the fabled "magic") that really sped up development of your standard CRUD apps. As far as I can tell, this was fairly novel in web development. Django didn't really have a focus on that, you spent a little (lot?) more time configuring. It's better now though.

Of course, at the complete opposite of the spectrum, you have very minimalist stuff like Flask (Python) or Sinatra (Ruby) which is doesn't include a lot of bells and whistles. You'll have to import your own ORM, templating, etc...

camus6• 14 years ago

Ruby has nothing to do with Python. Python is strongely typed and compiled into bytecode, just like java. It is just not the bloated and verbose language java is , which allows fast and pragmatic development.

mgkimsal• 14 years ago

I'll throw out another factor:

When Rails was introduced, there were no other substantive Ruby web frameworks - Ruby itself was relatively obscure compared to every other web-capable tech. As such, it (Rails) had no competition in the framework space. PHP, Java, Python and other languages all had competing web frameworks to choose from.

philwelch3• 14 years ago

You're making it sound like Ruby is a terrible language that's either much worse than Python or completely redundant with it. I simply don't think that's the case.

jshen3• 14 years ago

Maybe it's hard to build something like rails and get the details right? It's like asking why PC makers don't do a better job at copying apple.

ww5202• 14 years ago

It's called Play! Framework on the Java/Scala land. You got the benefits of both, ease of development and performance/scalability.

chii• 14 years ago

also dont forget grails!

Skoofoo• 14 years ago

Python's culture heavily encourages explicit, consistent code while Ruby's culture is a lot more flexible in that respect. Rails makes many assumptions by default and has an API that is based on clever coding for the sake of maximizing productivity. That stuff would likely not fly in the Python community.

vidarh3• 14 years ago

There are some of us Ruby users that find the Rails approach absolutely disgusting... I don't believe it maximize productivity either - the moment you need to deviate too much from the defaults you quickly descend into hell, trying to figure out what "magic" is happening behind your back.

mnutt3• 14 years ago

> but if you pass a certain (very unusual) level of traffic, you'll wish you'd made the extra effort

I'm not sure that's the case. Perhaps had they started out by trying to scale to their current levels they would never have gotten off the ground. When you start developing a system for a new company your largest obstacle is almost always lack of product/market fit.

gadders• 14 years ago

Isn't there some famous quote about premature optimisation? :-)

grey-area2• 14 years ago

If you get to the scale of twitter, and more importantly if you have written a real time messaging server with a web application framework, it doesn't matter which framework or language you started with as you're going to be completely rewriting your entire stack at some stage as different parts fail in order to deal with the load (unless you have an incredibly experienced team who has written a twitter equivalent before and scaled it to 15000 messages a second). There's no difference between ruby or python (or perl, or php) in that regard - they are all interpreted and relatively slow, which starts to matter at this scale. And also even if you had used java or c in the fist place, if you had an architecture not written with massive scale in mind, you probably wouldn't survive that growth without radical changes on every level of your stack.

Re ruby versus python, the popularity of rails is partly historical accident, partly that ruby is a nice language which doesn't get in the way and is ideally suited to this domain, and partly that rails is deals with lots of the basics of web development for you without getting in the way too much when you need to adapt it. None of that means ruby is better than python, but I'd disagree that people put up with ruby in order to use rails - it's a really nice language in its own right, but it is not highly performant (though it is getting better). For most websites of course, many of which can employ caching, that is a non-issue, even at large scale - witness the success of Wordpress in php which would not survive even modest loads without caching.

camus6• 14 years ago

python is not interpreted,it is compiled in bytecode just like java.

jpatokal• 14 years ago

Yup, and from experience, you're going to end up rewriting big chunks of your stack multiple times. (In a previous life, I worked on a team that grew a Java-based SMS gateway from an initial design limit of 10 msg/s on a single box to 10,000+ msg/s sustained, replicated across a high-availability cluster.) Props to the Twitter team for pulling it off, because at volumes like that you start to get into seriously arcane stuff like JVM garbage collection tweaking, or otherwise a full GC that halts all threads of execution for 30+ seconds will create entire pods of fail whales.

http://www.oracle.com/technetwork/java/javase/gc-tuning-6-14...

irahul6• 14 years ago

> What this says to me, a non-RoR user, is that it's harder to build websites with Java than with RoR, but if you pass a certain (very unusual) level of traffic, you'll wish you'd made the extra effort; otherwise, you'll be glad you didn't. (Extra effort isn't free.)

Twitter hasn't phased out Rails, it has replaced background services written in Ruby.

> Fine, but what I wish I understood was why RoR is so popular to begin with.

That is hard to explain. You will have to try it out yourself and compare with whatever you are currently using.

> why isn't one of them Python on Rails

As other responses pointed out, Python has Django. And no, Django isn't rails inspired. Django was developed independently. Also, the languages and philosophies differ significantly to have a Python on Rails.

neya4• 14 years ago

This is why I insist people to work on a robust stack from ground up, so it will be less painful in the long run. This is not to say that you shouldn't build a prototype in Rails to get everything up and running as quickly as possible and worry about scaling later, but, it is just my opinion that if you invest the time and effort in working with a robust stack (for example Scala+Lift), your investment will pay you off in the long run.

I've always admired rails for its flexibility and its enormous productivity boost, but all my serious applications are coded in Lift. I for one believe in "develop and forget", because I'd like to call myself a business guy than a programmer, though I'm deep into both. I like to spend more time expanding/marketing my business than worry about scaling it. But that's just my perspective.

JVM is terribly under-estimated and I realized this when I got started with Lift+Scala. Scala is a very powerful language and requires a totally different mindset (=functional). And Lift is fairly complex for those wishing to get started with it and has poor documentation, despite being a 5-year old Framework. But once you understand it fully (somehow), there's no looking back. Lift provides so many things out of the box, especially related to security (unlike PLay!), so it's kind of a trade-off you have to choose between. Even if you compare all the benchmarks, most of the JVM-based languages like Scala outperform even something like GO! (Ok, that's not fair, since GO is fairly new)

If you're interested in Scala, Coursera has a course on it by the creator of Scala himself (Martin Odersky).

mnutt3• 14 years ago

> I like to spend more time expanding/marketing my business than worry about scaling it.

If you're truly more interested in the business side, why don't you build it as quickly as possible in rails/django and then later if it warrants it you can hire some people to build it in lift/something else?

stock_toaster• 14 years ago

In addition, startups tend to pivot a few times, and agility is arguably more important early on than raw performance (depending on product of course).

neya4• 14 years ago

Very good point. Truth is, I want to keep down the hiring as minimum as possible, particularly when I plan to bootstrap. Imagine, I could eliminate hiring these people just to 'scale my app' because I chose a language/framework that doesn't scale well. There's some savings in this process. I could be wrong though, because I'm only speculating and I've never hit that traffic level, and probably never will.

DigitalSea• 14 years ago

I wonder if Node.JS would meet the needs of Twitter? It's marketed as a language for real-time applications that require a lot of concurrent connections and whatnot, not nearly as complicated as Java/Scala either but would it be stable enough to power a site like Twitter? The inner nerd in me is going haywire with the possibilities.

While most won't ever encounter the issues Twitter encountered using Ruby and Ruby on Rails these kinds of articles are very damaging for the Ruby language and Rails framework because even though I primarily still use PHP, Ruby & Rails are something I have a vested interest in as well and this will no doubt push potential newcomers away from the language.

sicxu• 14 years ago

Scalability is an architecture issue, not a programming language issue. You can certainly build linearly scalable system in Ruby. It just costs more to scale a Ruby app vs. an equivalent Java app. In the end, the tradeoff is between engineering cost and operating cost. When you spend 100k to hire an engineer and your traffic can be handled by a few boxes. Engineering productivity is your primary focus. As your traffic grows, you need more and more servers, server efficiency becomes more and more important. At some point, the savings in server cost justifies the increased cost in engineering effort and you make a switch from Ruby to Java.

jakejake2• 14 years ago

I would think that scaling the web servers to handle 15k requests per second would be relatively easy compared to scaling the database servers.

I would have thought that you could just throw cheap hardware at that problem, whereas the database would be a considerably complex scaling issue.

jacques_chester2• 14 years ago

Not to trivialise your question, because scaling to tens of thousands of database TPS transactions is difficult.

But it is commercially solved. If you turn up with a fistful of money, Oracle, IBM, Sybase and a bunch of other companies would love to handle that for you.

jakejake2• 14 years ago

probably projecting my own problems onto that one, hehe.

camus6• 14 years ago

And i say they should have use C++ directly, C++ is the only thing that scales ... what? oh sorry i meant Assembly. Nothing scales more than assembly, java is slow... why are we having that discussion again anyway ?

keymone2• 14 years ago

i wonder if invokedynamic was introduced before they started moving their stack and staff to Java - would jruby save them in that case?

Twitter survives election after Ruby-to-JVM move

Related Stories