Live data from Hacker News

Twitter survives election after Ruby-to-JVM move

theregister.co.uk

141–150 of 179 posts

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

#141
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…

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

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

#142
post #54
post #37

Earlier quoted context omitted.

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.

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.

pg's argument reminds me of plato's dialogues where socrates confronts sophistry and searches for a universal truth. At first sight, it seems hard to make a primary ordering of programming languages, because they focus on different areas (ease of use, speed of development, performance etc) and ordering those disjunct areas against each other seems to be impossible. However, it is still possible for a programming language to focus and excel on all those areas at the same time. I am still hopeful of a language for the next 100 years; be it Arc or something else.

As a happy user of Ruby, Ruby excels in many of its promises. I wish Ruby-MRI focuses a bit on performance in coming versions. The ruby community needs this guy who developed the V8 javascript engine to do the same performance leap here too.(Maybe Rubinius or JRuby already do) That said, let us not forget that Twitter performance requirement is kind of extreme for most startups, and most JVM based languages and foremost Java lag in ease of use, speed of development etc to be a viable option for a startup. (I exclude here Clojure, Scala, JRuby etc). For most startups speed of development is what matters.

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

#143
post #52
post #8

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

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

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.

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

#144

Earlier quoted context omitted.

I think I could write a scalable Twitter using mostly low-paid workers who manually write down the tweets and deliver them in person. It's just a matter of hiring enough workers now that I've designed this scalable distributed system.

Computers are easier (though perhaps less fun) to make than humans. Ruby is slow but it's close enough to Java that the numbers will still work out. Humans: probably not.

30x slower seems a bit of a stretch for "close enough": http://shootout.alioth.debian.org/u64q/benchmark.php?test=al...

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

#145

Earlier quoted context omitted.

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…

I think I could write a scalable Twitter using mostly low-paid workers who manually write down the tweets and deliver them in person. It's just a matter of hiring enough workers now that I've designed this scalable distributed system.

Compared to the OP, your post is just random, non-funny sarcasm. The OP has highlighted relevant data points.

1. Writing a system the second time is easier since you already know the pitfalls and avoid them.

2. Ruby, Python, Perl, Java... provide thin wrappers for the underlying IO system calls, and hence, Java IO isn't very different from Ruby IO when it comes to performance.

3. There are only a few CPU intensive tasks. It goes without saying that Java will kick Ruby's(pure Ruby; native extensions will be a different story)ass when it comes to CPU intensive tasks.

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

#146
post #99

Earlier quoted context omitted.

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

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

No need to get agressive over this :) I disagreed with your first comment regarding the dynamic nature of the JVM, and replied trying to explain why.

I posted the wikipedia link not as kind of an "appeal to authority", but to give the readers a full listing of bytecode instructions, so that they can check what I was saying for themselves.

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

It depends how you see things: the JVM can't possibly provide instructions for every possible user type, so apart from primitives, the other object types are passed around as pointers or references, but whenever you try to do something other than storing/loading them on the stack, the type checking kicks in, ensuring that the reference being manipulated has the right types.

For instance, the putfield instruction doesn't just take the field name where the top of the stack is going to get stored. It also takes the type of the field as a parameter, to ensure that the types are compatible.

Constrast this to Python's bytecode, where the equivalent STORE_NAME (or the other variants) doesn't ask you to provide type informations.

But then again, we might be splitting hairs here: since this type checking is happening at runtime (when the JVM is running your code), you could indeed question calling it "static typing", which is usually performed at compile time (an is partially performed by the java compiler for example).

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

#147
post #121

Earlier quoted context omitted.

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

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

Yes sorry that was an over-simplification due to ignorance - Ruby 1.9.3 and Python are both compiled to bytecode now, but still tend not to do as well in speed comparisons to the Java VM (which perhaps has just had more effort on optimisation). So in that sense it is like Java, but slower - for most people that really doesn't matter, but for twitter with this level of traffic, it probably would. You can of course run Ruby on the JVM now too, but I think that came too late for twitter.

What I found interesting from another twitter blog post linked from the article was that they are actually running on a modified version of Ruby 1.8.7 REE, not Ruby 1.9.x as you might expect, so that must really skew their comparisons![1] Anyway, there are a lot of variables in a huge system like twitter, so boiling it down to just a problem with Ruby performance seems pretty simplistic (as you'd expect from the register), and I seriously doubt they could have avoided this kind of rewrite and refactor of their entire stack in any language when hitting this sort of scale. To me it doesn't say much at all about Ruby as a language or whether it is suitable for websites.

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

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

#148
post #100

Earlier quoted context omitted.

The point where you are having scaling issues because of the language then you are really going to be past the worrying about bootstrapping/hiring stage. It sounds like you are spending time/effort worrying about scaling way before needed. If you can solve your problems you have today faster then I would do that, not hinder yourself today for possible problems way down the track.

Very valid point there dude. I don't know dude...maybe I just want things to be efficient right from ground up...Or it could be the after-effects of falling in love with Functional programming in Scala :)

There is plenty of merit using a language you enjoy.

A certain language might be twice as fast to get work done in, but you can be 10 times as fast if you are enjoying yourself and motivated.

I just wouldn't kid yourself that scaling is the reason for the choice. Just enjoying it is plenty of reason.

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

#149
post #116
post #63

Earlier quoted context omitted.

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!

and you can use Play from clojure too, if you think you are pragmatic enough...

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

#150

Earlier quoted context omitted.

http://en.wikipedia.org/wiki/Category:Project_management_sof... http://en.wikipedia.org/wiki/Category:Cloud_platforms

You can throw wikipedia links to try justify an argument ("hey, look at how many other projects there are!"), but GitHub and Heroku both leverage RoR heavily and both are incredibly large, successful products. Having competitors does not a failure make.

Q.E.D.
Post reply on HN