Live data from Hacker News

Twitter survives election after Ruby-to-JVM move

theregister.co.uk

91–100 of 179 posts

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

#91
post #84
post #78

This is why I insist people to work on a robust stack from ground up, so it will be less painful in the long run. This is not to say that you shouldn't build a prototype in Rails to get everything up and running as quickly as possible and worry about scaling later, but, it is just my opinion that if you invest the time and effort in working with a robust stack (for example Scala+Lift), your investment will pay you of…

> I like to spend more time expanding/marketing my business than worry about scaling it. If you're truly more interested in the business side, why don't you build it as quickly as possible in rails/django and then later if it warrants it you can hire some people to build it in lift/something else?

Very good point. Truth is, I want to keep down the hiring as minimum as possible, particularly when I plan to bootstrap. Imagine, I could eliminate hiring these people just to 'scale my app' because I chose a language/framework that doesn't scale well. There's some savings in this process. I could be wrong though, because I'm only speculating and I've never hit that traffic level, and probably never will.

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

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

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 matter which framework or language you started with as you're going to be completely rewriting your entire stack at some stage as different parts fail in order to deal with the load (unless you have an incredibly experienced team who has written a twitter equivalent before and scaled it to 15000 messages a second). There's no difference between ruby or python (or perl, or php) in that regard - they are all interpreted and relatively slow, which starts to matter at this scale. And also even if you had used java or c in the fist place, if you had an architecture not written with massive scale in mind, you probably wouldn't survive that growth without radical changes on every level of your stack.

Re ruby versus python, the popularity of rails is partly historical accident, partly that ruby is a nice language which doesn't get in the way and is ideally suited to this domain, and partly that rails is deals with lots of the basics of web development for you without getting in the way too much when you need to adapt it. None of that means ruby is better than python, but I'd disagree that people put up with ruby in order to use rails - it's a really nice language in its own right, but it is not highly performant (though it is getting better). For most websites of course, many of which can employ caching, that is a non-issue, even at large scale - witness the success of Wordpress in php which would not survive even modest loads without caching.

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

#93
post #84

Earlier quoted context omitted.

> I like to spend more time expanding/marketing my business than worry about scaling it. If you're truly more interested in the business side, why don't you build it as quickly as possible in rails/django and then later if it warrants it you can hire some people to build it in lift/something else?

In addition, startups tend to pivot a few times, and agility is arguably more important early on than raw performance (depending on product of course).

Agreed. But, probably my situation applies when you've come past all the pivoting and you've settled with one idea you decidedly are going to work on.

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

#94
post #37

The novice programmer says: "My language is better than yours." The wise programmer says: "Use the right tool for the job." Please HN, we're wiser than trending stories would suggest.

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.

> 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 "quickly building a product" or "quickly adding new features" to "rock-solid stable and fast", then you need to switch tools. Simple as that.

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

#95
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 :)

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

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

#96
post #91
post #84

Earlier quoted context omitted.

> I like to spend more time expanding/marketing my business than worry about scaling it. If you're truly more interested in the business side, why don't you build it as quickly as possible in rails/django and then later if it warrants it you can hire some people to build it in lift/something else?

Very good point. Truth is, I want to keep down the hiring as minimum as possible, particularly when I plan to bootstrap. Imagine, I could eliminate hiring these people just to 'scale my app' because I chose a language/framework that doesn't scale well. There's some savings in this process. I could be wrong though, because I'm only speculating and I've never hit that traffic level, and probably never will.

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.

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

#98
post #94
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.

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

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

#99

Earlier quoted context omitted.

"Python is fast enough for our site and allows us to produce maintainable features in record times, with a minimum of developers," said Cuong Do, Software Architect, YouTube.com. There are many dynamic user driven sites which have scaled well (far less downtime than Twitter) without switching to static compilation.

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 longs), dadd (for doubles), fadd (floats), etc.

The same is true for most other instructions: the other arithmetic instructions (div, sub, etc.), the comparison instructions (*cmp), pushing constants on the stack, setting and loading local variables, returning values from methods, etc.

http://en.wikipedia.org/wiki/Java_bytecode_instruction_listi...

InvokeDynamic, as you point it out, was added to make implementing dynamic languages on the JVM easier, because the JVM was too statically typed at its core.

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

#100
post #91

Earlier quoted context omitted.

Very good point. Truth is, I want to keep down the hiring as minimum as possible, particularly when I plan to bootstrap. Imagine, I could eliminate hiring these people just to 'scale my app' because I chose a language/framework that doesn't scale well. There's some savings in this process. I could be wrong though, because I'm only speculating and I've never hit that traffic level, and probably never will.

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 :)
Post reply on HN