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

171–179 of 179 posts

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

#171

Post by [deleted] »

mercurial wrote: post #170
blacksmythe wrote: post #169

Earlier quoted context omitted.

Because numerical processing is a major use case, Python has a number of techniques to easily speed up critical sections of code (numpy, cython, pypy). I am not aware of comparable features in Ruby.

Numpy is a dedicated library where the critical code is in C, but that's a library, hardly a language feature. I don't know if there is any numerical processing library in Ruby. Cython is not intrinsic to Python either. I see there is a ruby2c gem, but I have no idea how it compares to Cython. As for pypy, that's about switching to a different runtime, the same way Ruby people would go to JRuby. None of this turns Ru…

[deleted]

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

#172

Post by igouy »

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/

>> peformance difference is clear for virtually any static or dynamic language you care to name JavaScript

http://shootout.alioth.debian.org/u64/which-programs-are-fas...

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

#173

Post by igouy »

logn wrote: post #16
gary4gar wrote: post #9

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.

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

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

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

#174

Post by igouy »

thebluesky wrote: post #106
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.

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

No, JRuby is not 3-100x slower than Java.

Those 10 tiny tiny Ruby programs are 3-100x slower than the Java programs written for the tasks.

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

#175

Post by ishbits »

camus wrote: post #129
mercurial wrote: post #127

Earlier quoted context omitted.

> Python is strongely typed Like Ruby. > and compiled into bytecode Like JRuby. Python and Ruby are comparable languages. They are both high-level dynamic languages, with the same sort of tradeoffs (eg, you can do more with less characters than in most statically typed languages, at the expense of safety and performance). There are however significant differences in terms of philosophy, ecosystem and community betwee…

Except you dont need a JVM to get performances in python. Using a JVM destroys any perspective of cheap and easy deveployement. If i have to use a JVM , i'd certainly not use JRuby when i can get scala.

I deploy SpringMVC apps, using an embedded Jetty instance into much the same environments as I do Python apps based on Tornado or Twisted.

The biggest win for me is dependency management. One my maven file is setup right, I only need a JRE on the host.. Dependency management is a bit trickier with Python, perhaps for Ruby as well.

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

#176

Post by jakejake »

jacques_chester wrote: post #157
jakejake wrote: post #113

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.

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.

probably projecting my own problems onto that one, hehe.

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

#177

Post by justincormack »

thebluesky wrote: post #119
justincormack wrote: post #108

Earlier quoted context omitted.

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

The LuaJIT performance is pretty impressive for a dynamically typed language, but it's hard to deny the fact that mainstream dynamically typed languages our outperformed by their static counterparts.

Thats partly because they were not designed for performance. Lua of course was as it was designed partly for slow small systems. But pypy is getting on pretty well too and javascript, showing what you can do even if not designed for performance.

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

#178

Post by keymone »

pyrotechnick wrote: post #7

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

sir, troll more please
Post reply on HN