Live data from Hacker News

Twitter: From Ruby on Rails to the JVM [video]

ontwik.com

11–20 of 95 posts

Re: Twitter: From Ruby on Rails to the JVM [video]

#11
post #9

Earlier quoted context omitted.

I was surprised when I got some pushback on this concept at a local Django meetup last week. A lot of people believe that Python & Ruby-type languages are the backend languages of the future.

To be fair, you're very unlikely to ever have to solve the kinds of scaling problems Twitter has had to solve. You'll get your app off the ground faster with Python or Ruby.

You will get your app of the ground faster, but you're selling yourself short if you're a technology-based company thinking that you'll never have scaling problems. Competing against Twitter or any other social-based app you'll probably never encounter that level of scale, but any financial application will need to be both fast and handle the complexities that only the JVM can address.

Like he states at the end of the video, when describing the 7000+ tpm during the WWC:

"...we do things like Forex spikes upon our standard baseline growth. So right now the JVM is really the only mechanism that we can build upon that gives us the flexibility to do something like that."

Re: Twitter: From Ruby on Rails to the JVM [video]

#12

Earlier quoted context omitted.

It all depends on the problem. Dynamic languages like Ruby and Python are good for rapid development, but not for high volume, soft realtime problems like Twitter has. Just make sure to match your tools to you problems and try and oddly hack a solution with a tool that is not best for the job.

Yeah my contention was that they're great for certain phases but once you start reaching scaling problems the JVM might be the better solution.

Also, twitter is at a point where they can afford the best programmers, and where hardware efficiency becomes a big issue. In my experience, a lot of web-based small companies are more limited by skill, development practice than language and hardware usage. Only once you solved the former can you focus on the latter.

Re: Twitter: From Ruby on Rails to the JVM [video]

#13
I was recently in a quandary over the choice of technology. I started RoR and I really like it. However I was concerned about long term implications of that choice. The thing that I am taking from this talk is that I shouldn't worry about that, right now. If and when I need to scale, I will have enough resources to make a better choice. Resources that I don't have right now.

Re: Twitter: From Ruby on Rails to the JVM [video]

#14
post #8
post #5

One thing that wasn't touched was JRuby[1], on their site they state high performance and real threading as advantages. If twitter has (some of) the best ruby developer (mentioned somewhere at the end of the video), why have they neglected JRuby? Why is it no option? For legacy code with native extensions this makes sense. But is jruby slower, more memory hungry on the JVM then scala or clojure? I always though that…

JRuby is fast for a Ruby implementation, but it's still far, far slower than Scala or Java itself. http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

I do get that a dynamic language like Ruby will always be slower than a language like Java, which has primitives and where many things, including static method calls, are solved at compile time.

But citing the Alioth.Debian benchmarks? Really?

Dude, take a look at the source-code of those benchmarks sometimes -- they are completely useless ;)

Re: Twitter: From Ruby on Rails to the JVM [video]

#15
post #8

Earlier quoted context omitted.

JRuby is fast for a Ruby implementation, but it's still far, far slower than Scala or Java itself. http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

I do get that a dynamic language like Ruby will always be slower than a language like Java, which has primitives and where many things, including static method calls, are solved at compile time. But citing the Alioth.Debian benchmarks? Really? Dude, take a look at the source-code of those benchmarks sometimes -- they are completely useless ;)

If you want a fast dynamic language, take a look at Lua. It's surprisingly fast, especially LuaJIT, and pretty straight forward (almost boring really). The main downside is that there isn't the breadth of community around it.

Re: Twitter: From Ruby on Rails to the JVM [video]

#16

I was recently in a quandary over the choice of technology. I started RoR and I really like it. However I was concerned about long term implications of that choice. The thing that I am taking from this talk is that I shouldn't worry about that, right now. If and when I need to scale, I will have enough resources to make a better choice. Resources that I don't have right now.

Shopify is still 100% ROR and we serve hundreds of millions of requests. You will be fine :-)

It's a competitive advantage for us, we move faster then the rest of the market.

Re: Twitter: From Ruby on Rails to the JVM [video]

#17

Earlier quoted context omitted.

I was surprised when I got some pushback on this concept at a local Django meetup last week. A lot of people believe that Python & Ruby-type languages are the backend languages of the future.

People are going to defend their language of choice, but I have to look up to see what the big dogs are doing, try and understand why they're doing it and what type of influences they're under when it comes time to choose a technology stack to address and solve a problem. Ruby, and Python to certain extent with Django, suffers from the Rails attitude of opinionated development where either it's all Rails or nothing,…

Coming from a Java workshop, I have noticed the exact opposite - the majority of Java developers I have worked with are unwilling to touch or experiment with anything other than Java, even languages on the JVM like Scala; alternatively, I have noticed python developers are much more open and agile when it comes to moving in and out of other languages.

Re: Twitter: From Ruby on Rails to the JVM [video]

#18
post #5

One thing that wasn't touched was JRuby[1], on their site they state high performance and real threading as advantages. If twitter has (some of) the best ruby developer (mentioned somewhere at the end of the video), why have they neglected JRuby? Why is it no option? For legacy code with native extensions this makes sense. But is jruby slower, more memory hungry on the JVM then scala or clojure? I always though that…

I recall reading an interview with Evan Weaver that the problem with moving to JRuby was in client libraries they were using, not JRuby itself.

Re: Twitter: From Ruby on Rails to the JVM [video]

#19
post #8

Earlier quoted context omitted.

JRuby is fast for a Ruby implementation, but it's still far, far slower than Scala or Java itself. http://shootout.alioth.debian.org/u32/benchmark.php?test=all...

I do get that a dynamic language like Ruby will always be slower than a language like Java, which has primitives and where many things, including static method calls, are solved at compile time. But citing the Alioth.Debian benchmarks? Really? Dude, take a look at the source-code of those benchmarks sometimes -- they are completely useless ;)

They show the right order-of-magnitude differences. Taking them more seriously than that is a mistake.

Re: Twitter: From Ruby on Rails to the JVM [video]

#20
post #9

Earlier quoted context omitted.

To be fair, you're very unlikely to ever have to solve the kinds of scaling problems Twitter has had to solve. You'll get your app off the ground faster with Python or Ruby.

You will get your app of the ground faster, but you're selling yourself short if you're a technology-based company thinking that you'll never have scaling problems. Competing against Twitter or any other social-based app you'll probably never encounter that level of scale, but any financial application will need to be both fast and handle the complexities that only the JVM can address. Like he states at the end of th…

Plenty of companies do huge transaction volumes on dynamic languages. Twitter is a freak outlier. If you try to solve problems long before you actually have them chances are you'll come up with the wrong solutions.
Post reply on HN