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

111–120 of 179 posts

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

#111

Post by bad_user »

jawher wrote: post #99
bad_user wrote: post #73

Earlier quoted context omitted.

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

> 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 ... Not sure what gave you this impression, as the majority of Java bytecode instructions are typed. For example, the add instruction comes in typed variants: iadd (for ints), ladd (for l…

Arithmetic operations on numbers are not polymorphic, but polymorphism has nothing to do with static typing per se. You're being confused here by the special treatment the JVM gives to primitives, special treatment that was needed to avoid the boxing/unboxing costs, but that's a separate discussion and note that hidden boxing/unboxing costs can also happen in Scala, which treats numbers as Objects.

Disregarding primitives, the JVM doesn't give a crap about what types you push/pop the stack or what values you return.

invokeDynamic is nothing more than an invokeVirtual or maybe an invokeInterface, with the difference that the actual method lookup logic (specific to the Java language) is overridden by your own logic, otherwise it's subject to the same optimizations that the JVM is able to perform on virtual method calls, like code inlining:

http://cr.openjdk.java.net/~jrose/pres/200910-VMIL.pdf

> ... because the JVM was too statically typed at its core

Nice hand-waving of an argument, by throwing a useless Wikipedia link in there as some kind of appeal to authority.

I can do that too ... the core of the JVM (the HotSpot introduced in 1.4) is actually based on Strongtalk, a Smaltalk implementation that used optional-typing for type-safety, but not for performance:

http://strongtalk.org/ + http://en.wikipedia.org/wiki/HotSpot#History

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

#112

Post by Xylakant »

knowtheory wrote: post #45
wmil wrote: post #31

Earlier quoted context omitted.

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

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

Well, bundler solves a problem that's related, but tangential to what rubygems does. Rubygems is first and foremost a packaging format for libraries. It handles loading, provides a common format to specify dependencies (gemspec) and a default code layout for libs. It does not to dependency resolving.

So what people used to call "gem hell" was actually "I need to specify all my dependencies and take care of conflicts myself." That's what bundler does. And it uses rubygems to actually retrieve, install and load the gems.

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

#113

Post by jakejake »

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.

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

#114

Post by nwienert »

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/

How does that explain Julia[0]/Node.js? Both within 1-2x speed of C, I think static has less to do with it than you think.

[0] http://julialang.org/

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

#115

Post by camus »

thebluesky wrote: post #104
camus wrote: post #97

Earlier quoted context omitted.

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

Well github is quite profitable , maybe that's twitter's problem... what service does twitter provides that people are willing to pay for ? None...

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

#116

Post by chii »

ww520 wrote: post #63
SiVal wrote: post #32

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

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

also dont forget grails!

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

#117

Post by thebluesky »

cglee wrote: post #107
thebluesky wrote: post #90

Earlier quoted context omitted.

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

Relative to other tools we've used, Ruby has caused a disproportionate number of problems.

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

#118

Post by camus »

knowtheory wrote: post #39
SiVal wrote: post #32

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

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

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

#119

Post by thebluesky »

justincormack wrote: post #108
thebluesky wrote: post #101

Earlier quoted context omitted.

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).

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.

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

#120

Post by Xylakant »

nnq wrote: post #49
willvarfar wrote: post #42

Earlier quoted context omitted.

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

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

Well, there are several problems with MRI-1.8.x/REE that come into play when you try to go for raw performance. The biggest problem is probably the "stop the world" GIL that occurs around the GC and AFAIK around all external C calls. The second biggest problem is that the lack of multi-core capabilities. Both can bite you pretty badly when you're aiming for raw performance of a single process. They're both not as bad when you're doing web-level stuff where it matters little whether you start one, two or 20 processes to handle your load.
Post reply on HN