Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twitter survives election after Ruby-to-JVM move

theregister.co.uk

Post reply on HN
Print view View original

101–110 of 179 posts

Re: Twitter survives election after Ruby-to-JVM move

#101

Post by thebluesky »

extension wrote: post #88
logn wrote: post #16

Earlier quoted context omitted.

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

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…

Statically vs dynamically typed peformance difference is clear for virtually any static or dynamic language you care to name, it has nothing to do with the jvm being "tuned" for a language: http://shootout.alioth.debian.org/

Re: Twitter survives election after Ruby-to-JVM move

#102

Post by spullara »

suresk wrote: post #70
erichocean wrote: post #23

Earlier quoted context omitted.

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.

I'm not necessarily disagreeing with you (static typed languages are going to be faster on the JVM), but JRuby - partially with the help of invokedynamic, added in Java 7 - has come a long way performance-wise since Twitter began their rewrite. I wonder if they would have done anything different, had JRuby been where it is now?

JRuby, even when using a lot of Java based libraries, doesn't get you the performance boost you need — it is just incremental over Ruby and even then only with some code.

Re: Twitter survives election after Ruby-to-JVM move

#103

Post by sicxu »

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.

Re: Twitter survives election after Ruby-to-JVM move

#104

Post by thebluesky »

camus wrote: post #97
elchief wrote: post #3

JVM is a wonderful thing.

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

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

Re: Twitter survives election after Ruby-to-JVM move

#105

Post by xxbondsxx »

oelmekki wrote: post #98
zorbo wrote: post #94

Earlier quoted context omitted.

> 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 "quic…

Could you please tell me what fortran is the good tool for ? :) As much as I agree it's delusional to think one language may be adapted for virtually any kind of tasks, it seems way too much consensual to me to tell there is no such thing as bad or deprecated languages.

Fortan is great for FEM. Companies like Siemens are using millions of LOC of Fortran to virtually crash cars and explode bombs.

Also, Nastran got us to the moon (which is basically Fortran)

Re: Twitter survives election after Ruby-to-JVM move

#106

Post by thebluesky »

erichocean wrote: post #23
taligent wrote: post #12

Earlier quoted context omitted.

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

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.

...except that JRuby is 3-100x slower than Java: http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

Re: Twitter survives election after Ruby-to-JVM move

#107

Post by cglee »

thebluesky wrote: post #90
SoftwareMaven wrote: post #17

Earlier quoted context omitted.

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 Maserat…

> 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"

You must also think cars and SQL are also pure evil?

Re: Twitter survives election after Ruby-to-JVM move

#108

Post by justincormack »

thebluesky wrote: post #101
extension wrote: post #88

Earlier quoted context omitted.

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…

Statically vs dynamically typed peformance difference is clear for virtually any static or dynamic language you care to name, it has nothing to do with the jvm being "tuned" for a language: http://shootout.alioth.debian.org/

Only when they removed LuaJIT from the shootout, it is dynamic and fast (it was around where Java is in the benchmarks).

Re: Twitter survives election after Ruby-to-JVM move

#109

Post by ilamparithi »

jrockway wrote: post #36
scribu wrote: post #27

Earlier quoted context omitted.

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

I work at Google :)

I suppose it doesn't matter if you didn't work on similar scaling problems in Google.

Re: Twitter survives election after Ruby-to-JVM move

#110

Post by jrockway »

kooshball wrote: post #95
jrockway wrote: post #36

Earlier quoted context omitted.

I work at Google :)

Then you should really know better than to make statements like "I think I could write a scalable Twitter in mostly Ruby. And I've never written a line of Ruby in my life."

This isn't really a comment on Java, Ruby, Twitter, Google, or my programming ability. It's a comment about the fact that once you've designed a scalable distributed system, the constant factor runtime isn't so important.

Twitter has clearly engineered a working distributed system (or you would have read stories like "5% of Twitter users lost their tweets when our servers caught on fire last night"), so the fact that they wrote it in Scala or Java is largely irrelevant. They need fewer computers than they would have if they wrote it in Ruby again, and that's not something to discount, but I think it's technically possible to have a full Ruby stack do what Twitter does. And, they would have needed even fewer computers if they used C or C++. So it's clear that Java was a social choice (it had the right books, libraries, and stack of resumes) rather than an absolute must.

Besides, Ruby and Java both make the same C library calls to do I/O. So it all ends up being the same for everything except search, trending tweets, and other cpu-intensive analysis.

Post reply on HN