15 ms·

A Short Rant At Wired - The Second Coming Of Java

64 points by wiggly 13y ago

hobs 13y ago
It is unfortunate the state of "tech" writers these days.
quchen 13y ago
I stopped reading when he said "TIOBE"; nothing invalidates an opinion on programming languages more clearly. There should be a law like Godwin's you can freely yell on the internet every time you see it, resulting in general agreement to doing so.
- falcolas 13y ago
  You should have read further then - he was questioning where Wired was getting their data, not using it to back his own argument. "If Java rules the web I want to know what Wired are basing their conclusions on, except that it makes a more compelling article."
  - jamesbritt 13y ago
    ... not using it to back his own argument. Are you sure? Seems to me he referenced TIOBE as a counter to the claim that Java ruled the Web, and wondered where Wired was getting their data, since the TIOBE data contradicts Wired's claim. Let’s look at some numbers. The TIOBE Programming Community Index shows us information regarding the relative popularity of languages. Java is high up there, Ruby also features. Scala and Clojure just don’t have enough people using them yet to break the top 20 which still includes COBOL, pilloried by all as an abomination to work with. As of today Scala gets a mention at number 42 with 0.3% share. This is unfair though, these numbers are not segmented by industry. We really need to look at numbers for web sites only. Before we leave these numbers though it is interesting to point out that the Java ranking is very obviously trending downwards in the TIOBE index.
tom_b 13y ago
An intriguing part of the article asks about the Twitter Ruby-to-Java migration and posits that any language would be fine for a services architecture. I'm not much of an object-oriented hacker, but when I was at larger IT firms, what several Java codebases shared was a common use of design patterns. It seems that this sharing of what may be considered a common vocabulary essentially makes it much easier for Java devs to jump into any project and follow the "accepted" usages in a way that perhaps other languages do not? So you are scaling up your dev team, it's infinitely easier to recruit acceptable Java candidates than say, Scala hackers? I do want to mention that my impression of Twitter is that there is definitely a polyglot JVM environment there (Scala, Clojure). This feels like a bigger issue to me than I'd like it to be - in particular that Java programming opportunities vastly outnumber, say Ruby, Scala, Clojure, etc, hacking jobs.
- justinsb 13y ago
  I believe that strong typing is a much bigger factor than design patterns in supporting big codebases, and allowing people new to the codebase to contribute productively. Once you go beyond a small project, it's really nice to have the compiler on your side here! In terms of the pool of total developers, the argument is that "A-grade" developers use Scala and/or Java, "B-grade" developers only use Java, so a Scala developer is rarer but more likely to be an A-grade developer. But of course, once this is known then the B-grade developers learn Scala. This is probably what happened to Ruby - it was little known, so all the Ruby developers were 10x. Now everyone learns Rails, and Rails + Ruby teams are rapidly reverting to the mean. But yes, I do agree that we've figured out what good Java code looks like now, although it took us 10-15 years to do so. And we haven't hit the 10 year mark on Scala, Ruby, Clojure etc...
  - cageface 13y ago
    Once you go beyond a small project, it's really nice to have the compiler on your side here! Absolutely. Mobile dev brought me back to compiled languages after a long stint in Ruby and the advantages of static typing for performance, correctness, and tooling are so overwhelming that I doubt I'll ever work in a dynamic language by choice again.
jt2190 13y ago
Great rant, with the most important takeaway that no software written by two guys in a garage ends up scaling to millions of users without major changes to its architecture: > More importantly Twitter re-architected their system > when they found performance problems...
dcc1 13y ago
So JAVA is reborn because twitter changed to it? lol
- Ygg2 13y ago
  No, Java is reborn, because someone paid for an article, duh!
- diydsp 13y ago
  As someone working close with tech writers, I suggest (project) that the thing that precipitated this article is the realization that the JVM can run multiple languages. That's the kind of thing that is just science-fiction-y and just break-the-rules-y enough that it blows tech writers' minds and to some extent their audience. It speaks to the part of them (us) that wants to believe things like, "I knew that big company Sun couldn't do everything perfect, because they're BIG and they're a CORPORATION. I knew there was a deeper way to use technology, and isn't it just inspiring/trippy/deep that a VIRTUAL machine can so something it's totally unintended for?!?!?! lolomgcyber those hackers are breaking the rules established by The Man so we can have our super-slick free text messaging capabilities #mind #blown" :)
leothekim 13y ago
"I would absolutely love to know what it is about Rails that Twitter found stopped them from working on it together. Please, if you work there, I am dying to know." I don't work at Twitter, and I'm whitewashing a bit because I'm at work, but the consistent line I've heard from engineers there[1] and from the press[2] is performance. Plus, Scala has shares some linguistic niceties with Ruby that Java doesn't, so it's a little bit more of a natural fit. From my own experience with Scala, the reason to go in a service-oriented direction is, to say the least, make your compiles go faster over smaller isolated bits of functionality in your app. Scala type safety is awesome. Scala compiles, much less so. Ruby still runs at Twitter, but my understanding is that the more recent engineers there are afraid to touch what's there for fear of blowing things up. [1] http://blog.redfin.com/devblog/2010/05/how_and_why_twitter_uses_scala.html#.UkWZJ2T1LmY http://blog.redfin.com/devblog/2010/05/how_and_why_twitter_u... [2] http://techcrunch.com/2008/05/01/twitter-said-to-be-abandoning-ruby-on-rails/ http://techcrunch.com/2008/05/01/twitter-said-to-be-abandoni...
- pico303 13y ago
  If I recall, Rails got the bad rap early on because Twitter thought it was the cause. It turned out they were making synchronous calls to a Jabber server, and something in that connection was getting overloaded and causing their apps to hang. I'm not saying Ruby doesn't have a performance issue over something like a JVM-based language, Go, or Haskell, but the Twitter example works better as an example of the need to debug, benchmark, and test all aspects of your application. Don't just leap to conclusions about problems without information.
  - dragonwriter 13y ago
    > If I recall, Rails got the bad rap early on because Twitter thought it was the cause. IIRC, it got a bad rap because of one blog post by a Twitter dev that seemed to suggest that Ruby and/or Rails was the cause, which was later followed by a more in depth explanation from Twitter of their reasoning, which didn't place the blame there, but by that time Ruby/Rails haters had permanently latched on to the "Rails was killing Twitter and that had to leave to survive" meme and facts were no longer relevant.
citras 13y ago
I think that the general idea is that many companies that employ ruby based technologies have been making a switch away from them. The reason is simply scale, it's not a matter of "oh java's the new thing because everyone's switching back to it" Java has always been there and it will be around for a long time. People are just now realizing what a great platform the JVM is and since languages like Scala, Clojure and Groovy exist on-top of the JVM it allows large complex systems to be created in a language agnostic manner because they will all run on the same platform. Interop between other languages and java on the JVM aren't always nice but the fact that it's possible lets you leverage the many java resources that exist. For example SummingBird https://blog.twitter.com/2013/streaming-mapreduce-with-summingbirg https://blog.twitter.com/2013/streaming-mapreduce-with-summi... . SummingBird is a Scala platform built on top of Storm (a Clojure based real time computation system) and Scalding (a Scala adaption of Cascading (a Java library) which is used for writing map-reduce jobs easily) and they work beautifully together. So in my opinion their switch to the JVM and embracing of it was a smart move.
bluedino 13y ago
Before Java gets all the credit, what are they using to store and publish all those tweets?
Xorlev 13y ago
I'd say a major advantage of the JVM is the lack of a GIL. Ruby has one. JRuby is slowly eroding that advantage. That being said, it's much easier to write performant code on the JVM with the right tools. Static types and the discouragement of metaprogramming (except in Groovy, and let me tell you all about how fun that is) help with that. Groovy would be the JVM's Ruby equivalent (if JRuby didn't exist). It's cleaner, faster to write in, and very non-obvious what is and isn't performant. I think an SOA Ruby architecture would have helped Twitter, but as a startup built on the JVM (and experience with Rails/Ruby) the JVM's performance is a key factor for us. Not to say that Ruby or Python can't be performant too, but there's a reason it's used. http://www.techempower.com/benchmarks/#section=data-r6&hw=i7&test=db&f=htsq2o-hrbf9c-8 http://www.techempower.com/benchmarks/#section=data-r6&hw=i7... While these benchmarks aren't conclusive, Rails is definitely built to be friendly and encourage developer productivity, not raw performance. Many JVM frameworks are built to be faster at the expense of more time developing. We use Dropwizard and get a lot more bang for our buck when it comes to servers. I don't think most developers really consider the performance aspects of downstream services ... top-level services rarely see the brunt of load, that happens a few levels into your SOA graph.
bhauer 13y ago
I sympathize with your anger at the Wired article. I too read it and cringed at the misrepresentations. It was either carelessness or a desire to dumb down the subject matter. To my mind, the article is a demonstration of how poorly the media cover just about everything. When you or I read articles about subjects wherein we are not experts, we (or at least I) assume that they are well-researched and accurate. But when we read articles about subjects in which we have expertise, I find I'm routinely dismayed at the inaccuracies. I am no longer surprised by this, but still bothered. It casts a huge cloud of doubt over everything I read in the media. Therefore, I found your rant delightful. Nevertheless, I feel some of your points are subject to debate. You criticize the characterization of JVM as the star of the show affording Twitter and others the ability to scale more easily, considering these efforts were necessarily coupled with a rearchitecture of their entire infrastructure. Of course there is truth in your point, but minimizing the role of the JVM is unfair. The JVM, and especially its higher-performance languages—which include Java, Scala, and Clojure, is a big star in our web application frameworks benchmarks charts [1]. With respect to high scalability opinions vary, but I lean toward the side that believes that while very high scale is ultimately a matter of horizontal addition of servers, a great deal of complexity and pain can be avoided by servers simply being fast at what they do. When platforms perform not merely a few percentage points apart but an order of magnitude (or more!), it's not reasonable—again in my opinion—to ignore raw performance. Simply being faster—massively faster—is like opening a pressure relief valve that gives you a lot of architectural breathing room. Yes, Ruby runs on the JVM, but not all languages on the JVM have proven to reap the benefits. We have not yet observed JRuby demonstrating a compelling superiority to MRI Ruby. Also, as others here have pointed out, many believe that maintaining a large system is aided by a language with type safety. I personally am considerably more productive with a modern statically typed language than any dynamic language. When I make typo-grade errors in dynamic code, and that code makes it to a testing round, or even worse a staging or production environment, I have lost huge amounts of productivity. I end up feeling embarrassed and I long for a static language to prevent this kind of silly failure. Type safety preference isn't a matter that will be settled any time soon or ever, but I believe that at least the general consensus is that for large systems, stricter languages can make maintenance less painful. [1] http://www.techempower.com/benchmarks/#section=data-r6&hw=i7&test=json http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...
programminggeek 13y ago
I will say that Java, Scala, or any compiled JVM language will run code a lot faster than Ruby. So will Go, so will C#, so will C++. Ruby isn't about fast, it's about expressiveness and programmer happiness. If you wanted fast, you'd use a compiled language. If you want fast and ruby syntax, you might use Mirah, which is great btw. In either case, I don't think that twitter made a mistake at all. Everything I've read says that 1 java server =~ 10 ruby servers and twitter isn't the only one who has said this. So, if you are talking about going from 10,000 machines to 1,000 machines that's saving 9,000 x $1,000 or about $900,000. At that scale machine cost does matter. Most developers will never work at that scale so it is hard to understand that set of requirements, but at a certain point it's less about how fast you can write CRUD ops or other forms over data type things and more about making sure everything runs as fast and reliably as possible.
- berntb 13y ago
  >>Everything I've read says that 1 java server =~ 10 ruby servers I believe that is roughly correct. I'd add two points: - This goes about the same for all the scripting languages and the faster compiled languages. (+) - You should consider, and might even earn time, by first doing a scripting language implementation and then port it to C/C++/Java/etc, instead of going to C/C++/etc directly. (But all this is more or less conventional wisdom, afaik.) (+) Some lisp variants might be able to be as expressive as a scripting language while almost as fast as a compiled language. I don't really know that world since quite a few years.
AlisdairO 13y ago
I found this article kinda painful. > Does the JVM provide better raw performance than Ruby? Yeah, okay, you got me, it does. So let’s also mention that one of the languages that runs on the JVM these days is Ruby, and it gets a performance boost when run there. We can mention that, but let's be careful to be clear that JRuby is a bit faster than Ruby, and not even remotely comparable to straight Java (or Scala) performance. To the extent that I'm not even sure why you would mention this, when it's a wildly misleading point. > Perhaps you’re talking about factoring tools? Maybe? I don’t see how that stops people from working on it together though. > Source code control doesn’t care what language you write in, and that is the main tool we use to allow multiple people to collaboratively modify code so I’m feeling stumped. For me, I'd be talking about tools like 'find me everywhere in my enormous codebase where this version of this method gets called, quickly'. I'd be talking about all the tools that make it so the maintenance programmer who has never seen your code before can alter it with a high degree of confidence that they're not going to accidentally break something. The idea that if you have source code control you've got all you need is mad - it might be the case for small projects with low employee turnover, but it certainly doesn't generalise. I think Ruby is a wonderful language, but it doesn't surprise me that you might want to switch to something else when you need to scale up both your operations and your enterprise size.
PaulHoule 13y ago
I don't think Java is as bad a language as some people think it is. Personally I write very concise Java code that is full of functional ideas. Tools like Guava, Spring and language features such as static imports, as well as just having the value that verbosity is a problem, can lead to Java code that is fast to write and easy to understand. When people are doing rapid prototyping in a REPL, I'm writing unit tests in my IDE, and rather than scrolling off the screen and into oblivion, these tests are incorporated into my project right away and always watching my butt. If you want a REPL, Groovy is great. For instance, one time I was trying to figure out what was going wrong with a Hazelcast cluster, and I was able to create a Hazelcast client in Groovy just by puncing in the maven coordinates for Hazelcast and it was a lot like working with the MySQL or mongodb db shells. I think the main problem with Java is the total complexity of the ecosystem, and the fact that it requires wisdom to use well more so than intelligence. Personally I have been bouncing back and forth between Java and other programming languages for years. I was programming it back when it was in beta, and back then it took me about a year of experience to be able to write reusuable OO code that was worth reusing. More recently I got back into with two gigs for companies that had huge maven systems (30+ projects) and it was stressful a while, particularly when a large number of SNAPSHOT version releases, my internet connection was slow, and everything was half-baked. In a situation like that where you have to get on top of everything that's specific to a large codebase, you've got a 20-minute build process, no real project management (in one place the project manager quit the team after she got bitched out by my boss) and, if you're really unlucky, you're the last person to touch the code before it goes to QA, it's stressful. When I went back to coding for my own account, I read the maven documentation from cover to cover on my nook when I was working out at the gym and now my build process is faster than my car can drive the quarter mile and I intend to keep it that way. I think it is tougher for new programmers to get on board of it and a lot of the problem is that companies are trying to look for 10x programmers when they really should be building a 10x organization. For instance, a 10x change can be had by getting a 20 minutes build process down to 2 minutes. It's not science fiction. Sometimes team members and the boss will say that this "isn't a customer requirement" or "you're not being a team player" if you want to speed up the build, but I know the customer wants the job done quickly and the job done right, and speeding up the build process 10 times is the fastest way to attain either of those goals.
yk 13y ago
Unfortunately this is the state of journalism today. In the length of an article it is only possible to make one point, at least outside of a dense article aimed at a specialist audience. Additionally the article should seem to be relevant, that means that its single point need to be exaggerated until it seems earth shattering. And journalists are not really payed to research a topic in depth, but to write articles. So this is at least the impression I get from every article, where I actually know something about the topic. In theoretical physics every article describes one paper, and calls it a break through towards quantum gravity. Independent if this is a cute toy model, a interesting trick to calculate some technical problem or a actual attempt at quantum gravity, in which case there is certainly no data to back up the theory and the theory is almost certainly wrong. Another thing is any reporting about nuclear energy, either the article is wildly exaggerating the dangers of nuclear energy or it is wildly overstating the necessity of nuclear energy. ( Nuclear energy is IMHO a particularly nasty example for articles, because the dangers are extremely model dependent, so to inform a lay audience one would need an entire book.) And for programming, well the wired article did not strike me as a particular bad offender. This would be tolerable, if it would not bias the political process. The current German president, Joachim Gauck, is a nice example. [1] In 2010 the, in this context center-left, SPD had no chance at electing their own candidate, so they attempted a PR coup by nominating a guy who is a hero for conservatives, while the conservative CDU did elect a career politician. Much to the dismay of conservative talking heads. Last year, the president had to resign [2] and chancellor Merkel did nominate Gauck, knowing that now the SPD is on the hook because he was their candidate. And all political commentators in Germany did just dust off their opinion pieces from two years ago. In conclusion, I have no idea how to fix journalism. But I think that better journalism is badly needed. Or else the control loop for the political process has less and less input from actual facts and deep thought and is only controlled by some self consistent PR bullshit. Edit: Clarified the conclusion. [1] In Germany the president has a largely ceremonial role and is elected by an assembly of the parliament and (some members of) the state parliaments. [2] Itself only a media phenomenon.
cgag 13y ago
I feel like people ignore the fact that many of us find Clojure and Scala more expressive and fun than ruby, not just much more performant.
auggierose 13y ago
What's particularly funny is that today, Java is the poster child for performance. I remember when I was giving a talk in 1999 where I said that HotSpot is a game changer, and its lacking performance will not be an issue any more, I was laughed at.
abalone 13y ago
Twitter Engineering recently posted about their move to the JVM in detail. It's worth a read. It wasn't just about a move to a service oriented architecture. They also got well over 10X performance gain out of each machine by moving to the JVM. (They attribute it to better concurrency.) See: https://blog.twitter.com/2013/new-tweets-per-second-record-and-how https://blog.twitter.com/2013/new-tweets-per-second-record-a... I think the article's methodology is fine. It's not about the most popular languages in terms if developer head count. It's looking at what powers the biggest sites.

64 points by wiggly 13y ago

hobs 13y ago

It is unfortunate the state of "tech" writers these days.

I stopped reading when he said "TIOBE"; nothing invalidates an opinion on programming languages more clearly. There should be a law like Godwin's you can freely yell on the internet every time you see it, resulting in general agreement to doing so.

falcolas 13y ago
You should have read further then - he was questioning where Wired was getting their data, not using it to back his own argument. "If Java rules the web I want to know what Wired are basing their conclusions on, except that it makes a more compelling article."
- jamesbritt 13y ago
  ... not using it to back his own argument. Are you sure? Seems to me he referenced TIOBE as a counter to the claim that Java ruled the Web, and wondered where Wired was getting their data, since the TIOBE data contradicts Wired's claim. Let’s look at some numbers. The TIOBE Programming Community Index shows us information regarding the relative popularity of languages. Java is high up there, Ruby also features. Scala and Clojure just don’t have enough people using them yet to break the top 20 which still includes COBOL, pilloried by all as an abomination to work with. As of today Scala gets a mention at number 42 with 0.3% share. This is unfair though, these numbers are not segmented by industry. We really need to look at numbers for web sites only. Before we leave these numbers though it is interesting to point out that the Java ranking is very obviously trending downwards in the TIOBE index.

tom_b 13y ago

An intriguing part of the article asks about the Twitter Ruby-to-Java migration and posits that any language would be fine for a services architecture. I'm not much of an object-oriented hacker, but when I was at larger IT firms, what several Java codebases shared was a common use of design patterns. It seems that this sharing of what may be considered a common vocabulary essentially makes it much easier for Java devs to jump into any project and follow the "accepted" usages in a way that perhaps other languages do not? So you are scaling up your dev team, it's infinitely easier to recruit acceptable Java candidates than say, Scala hackers? I do want to mention that my impression of Twitter is that there is definitely a polyglot JVM environment there (Scala, Clojure). This feels like a bigger issue to me than I'd like it to be - in particular that Java programming opportunities vastly outnumber, say Ruby, Scala, Clojure, etc, hacking jobs.

justinsb 13y ago
I believe that strong typing is a much bigger factor than design patterns in supporting big codebases, and allowing people new to the codebase to contribute productively. Once you go beyond a small project, it's really nice to have the compiler on your side here! In terms of the pool of total developers, the argument is that "A-grade" developers use Scala and/or Java, "B-grade" developers only use Java, so a Scala developer is rarer but more likely to be an A-grade developer. But of course, once this is known then the B-grade developers learn Scala. This is probably what happened to Ruby - it was little known, so all the Ruby developers were 10x. Now everyone learns Rails, and Rails + Ruby teams are rapidly reverting to the mean. But yes, I do agree that we've figured out what good Java code looks like now, although it took us 10-15 years to do so. And we haven't hit the 10 year mark on Scala, Ruby, Clojure etc...
- cageface 13y ago
  Once you go beyond a small project, it's really nice to have the compiler on your side here! Absolutely. Mobile dev brought me back to compiled languages after a long stint in Ruby and the advantages of static typing for performance, correctness, and tooling are so overwhelming that I doubt I'll ever work in a dynamic language by choice again.

jt2190 13y ago

Great rant, with the most important takeaway that no software written by two guys in a garage ends up scaling to millions of users without major changes to its architecture: > More importantly Twitter re-architected their system > when they found performance problems...

dcc1 13y ago

So JAVA is reborn because twitter changed to it? lol

Ygg2 13y ago
No, Java is reborn, because someone paid for an article, duh!
diydsp 13y ago
As someone working close with tech writers, I suggest (project) that the thing that precipitated this article is the realization that the JVM can run multiple languages. That's the kind of thing that is just science-fiction-y and just break-the-rules-y enough that it blows tech writers' minds and to some extent their audience. It speaks to the part of them (us) that wants to believe things like, "I knew that big company Sun couldn't do everything perfect, because they're BIG and they're a CORPORATION. I knew there was a deeper way to use technology, and isn't it just inspiring/trippy/deep that a VIRTUAL machine can so something it's totally unintended for?!?!?! lolomgcyber those hackers are breaking the rules established by The Man so we can have our super-slick free text messaging capabilities #mind #blown" :)

leothekim 13y ago

"I would absolutely love to know what it is about Rails that Twitter found stopped them from working on it together. Please, if you work there, I am dying to know." I don't work at Twitter, and I'm whitewashing a bit because I'm at work, but the consistent line I've heard from engineers there[1] and from the press[2] is performance. Plus, Scala has shares some linguistic niceties with Ruby that Java doesn't, so it's a little bit more of a natural fit. From my own experience with Scala, the reason to go in a service-oriented direction is, to say the least, make your compiles go faster over smaller isolated bits of functionality in your app. Scala type safety is awesome. Scala compiles, much less so. Ruby still runs at Twitter, but my understanding is that the more recent engineers there are afraid to touch what's there for fear of blowing things up. [1] http://blog.redfin.com/devblog/2010/05/how_and_why_twitter_uses_scala.html#.UkWZJ2T1LmY http://blog.redfin.com/devblog/2010/05/how_and_why_twitter_u... [2] http://techcrunch.com/2008/05/01/twitter-said-to-be-abandoning-ruby-on-rails/ http://techcrunch.com/2008/05/01/twitter-said-to-be-abandoni...

pico303 13y ago
If I recall, Rails got the bad rap early on because Twitter thought it was the cause. It turned out they were making synchronous calls to a Jabber server, and something in that connection was getting overloaded and causing their apps to hang. I'm not saying Ruby doesn't have a performance issue over something like a JVM-based language, Go, or Haskell, but the Twitter example works better as an example of the need to debug, benchmark, and test all aspects of your application. Don't just leap to conclusions about problems without information.
- dragonwriter 13y ago
  > If I recall, Rails got the bad rap early on because Twitter thought it was the cause. IIRC, it got a bad rap because of one blog post by a Twitter dev that seemed to suggest that Ruby and/or Rails was the cause, which was later followed by a more in depth explanation from Twitter of their reasoning, which didn't place the blame there, but by that time Ruby/Rails haters had permanently latched on to the "Rails was killing Twitter and that had to leave to survive" meme and facts were no longer relevant.

citras 13y ago

I think that the general idea is that many companies that employ ruby based technologies have been making a switch away from them. The reason is simply scale, it's not a matter of "oh java's the new thing because everyone's switching back to it" Java has always been there and it will be around for a long time. People are just now realizing what a great platform the JVM is and since languages like Scala, Clojure and Groovy exist on-top of the JVM it allows large complex systems to be created in a language agnostic manner because they will all run on the same platform. Interop between other languages and java on the JVM aren't always nice but the fact that it's possible lets you leverage the many java resources that exist. For example SummingBird https://blog.twitter.com/2013/streaming-mapreduce-with-summingbirg https://blog.twitter.com/2013/streaming-mapreduce-with-summi... . SummingBird is a Scala platform built on top of Storm (a Clojure based real time computation system) and Scalding (a Scala adaption of Cascading (a Java library) which is used for writing map-reduce jobs easily) and they work beautifully together. So in my opinion their switch to the JVM and embracing of it was a smart move.

bluedino 13y ago

Before Java gets all the credit, what are they using to store and publish all those tweets?

Xorlev 13y ago

I'd say a major advantage of the JVM is the lack of a GIL. Ruby has one. JRuby is slowly eroding that advantage. That being said, it's much easier to write performant code on the JVM with the right tools. Static types and the discouragement of metaprogramming (except in Groovy, and let me tell you all about how fun that is) help with that. Groovy would be the JVM's Ruby equivalent (if JRuby didn't exist). It's cleaner, faster to write in, and very non-obvious what is and isn't performant. I think an SOA Ruby architecture would have helped Twitter, but as a startup built on the JVM (and experience with Rails/Ruby) the JVM's performance is a key factor for us. Not to say that Ruby or Python can't be performant too, but there's a reason it's used. http://www.techempower.com/benchmarks/#section=data-r6&hw=i7&test=db&f=htsq2o-hrbf9c-8 http://www.techempower.com/benchmarks/#section=data-r6&hw=i7... While these benchmarks aren't conclusive, Rails is definitely built to be friendly and encourage developer productivity, not raw performance. Many JVM frameworks are built to be faster at the expense of more time developing. We use Dropwizard and get a lot more bang for our buck when it comes to servers. I don't think most developers really consider the performance aspects of downstream services ... top-level services rarely see the brunt of load, that happens a few levels into your SOA graph.

bhauer 13y ago

I sympathize with your anger at the Wired article. I too read it and cringed at the misrepresentations. It was either carelessness or a desire to dumb down the subject matter. To my mind, the article is a demonstration of how poorly the media cover just about everything. When you or I read articles about subjects wherein we are not experts, we (or at least I) assume that they are well-researched and accurate. But when we read articles about subjects in which we have expertise, I find I'm routinely dismayed at the inaccuracies. I am no longer surprised by this, but still bothered. It casts a huge cloud of doubt over everything I read in the media. Therefore, I found your rant delightful. Nevertheless, I feel some of your points are subject to debate. You criticize the characterization of JVM as the star of the show affording Twitter and others the ability to scale more easily, considering these efforts were necessarily coupled with a rearchitecture of their entire infrastructure. Of course there is truth in your point, but minimizing the role of the JVM is unfair. The JVM, and especially its higher-performance languages—which include Java, Scala, and Clojure, is a big star in our web application frameworks benchmarks charts [1]. With respect to high scalability opinions vary, but I lean toward the side that believes that while very high scale is ultimately a matter of horizontal addition of servers, a great deal of complexity and pain can be avoided by servers simply being fast at what they do. When platforms perform not merely a few percentage points apart but an order of magnitude (or more!), it's not reasonable—again in my opinion—to ignore raw performance. Simply being faster—massively faster—is like opening a pressure relief valve that gives you a lot of architectural breathing room. Yes, Ruby runs on the JVM, but not all languages on the JVM have proven to reap the benefits. We have not yet observed JRuby demonstrating a compelling superiority to MRI Ruby. Also, as others here have pointed out, many believe that maintaining a large system is aided by a language with type safety. I personally am considerably more productive with a modern statically typed language than any dynamic language. When I make typo-grade errors in dynamic code, and that code makes it to a testing round, or even worse a staging or production environment, I have lost huge amounts of productivity. I end up feeling embarrassed and I long for a static language to prevent this kind of silly failure. Type safety preference isn't a matter that will be settled any time soon or ever, but I believe that at least the general consensus is that for large systems, stricter languages can make maintenance less painful. [1] http://www.techempower.com/benchmarks/#section=data-r6&hw=i7&test=json http://www.techempower.com/benchmarks/#section=data-r6&hw=i7...

programminggeek 13y ago

I will say that Java, Scala, or any compiled JVM language will run code a lot faster than Ruby. So will Go, so will C#, so will C++. Ruby isn't about fast, it's about expressiveness and programmer happiness. If you wanted fast, you'd use a compiled language. If you want fast and ruby syntax, you might use Mirah, which is great btw. In either case, I don't think that twitter made a mistake at all. Everything I've read says that 1 java server =~ 10 ruby servers and twitter isn't the only one who has said this. So, if you are talking about going from 10,000 machines to 1,000 machines that's saving 9,000 x $1,000 or about $900,000. At that scale machine cost does matter. Most developers will never work at that scale so it is hard to understand that set of requirements, but at a certain point it's less about how fast you can write CRUD ops or other forms over data type things and more about making sure everything runs as fast and reliably as possible.

berntb 13y ago
>>Everything I've read says that 1 java server =~ 10 ruby servers I believe that is roughly correct. I'd add two points: - This goes about the same for all the scripting languages and the faster compiled languages. (+) - You should consider, and might even earn time, by first doing a scripting language implementation and then port it to C/C++/Java/etc, instead of going to C/C++/etc directly. (But all this is more or less conventional wisdom, afaik.) (+) Some lisp variants might be able to be as expressive as a scripting language while almost as fast as a compiled language. I don't really know that world since quite a few years.

AlisdairO 13y ago

I found this article kinda painful. > Does the JVM provide better raw performance than Ruby? Yeah, okay, you got me, it does. So let’s also mention that one of the languages that runs on the JVM these days is Ruby, and it gets a performance boost when run there. We can mention that, but let's be careful to be clear that JRuby is a bit faster than Ruby, and not even remotely comparable to straight Java (or Scala) performance. To the extent that I'm not even sure why you would mention this, when it's a wildly misleading point. > Perhaps you’re talking about factoring tools? Maybe? I don’t see how that stops people from working on it together though. > Source code control doesn’t care what language you write in, and that is the main tool we use to allow multiple people to collaboratively modify code so I’m feeling stumped. For me, I'd be talking about tools like 'find me everywhere in my enormous codebase where this version of this method gets called, quickly'. I'd be talking about all the tools that make it so the maintenance programmer who has never seen your code before can alter it with a high degree of confidence that they're not going to accidentally break something. The idea that if you have source code control you've got all you need is mad - it might be the case for small projects with low employee turnover, but it certainly doesn't generalise. I think Ruby is a wonderful language, but it doesn't surprise me that you might want to switch to something else when you need to scale up both your operations and your enterprise size.

PaulHoule 13y ago

I don't think Java is as bad a language as some people think it is. Personally I write very concise Java code that is full of functional ideas. Tools like Guava, Spring and language features such as static imports, as well as just having the value that verbosity is a problem, can lead to Java code that is fast to write and easy to understand. When people are doing rapid prototyping in a REPL, I'm writing unit tests in my IDE, and rather than scrolling off the screen and into oblivion, these tests are incorporated into my project right away and always watching my butt. If you want a REPL, Groovy is great. For instance, one time I was trying to figure out what was going wrong with a Hazelcast cluster, and I was able to create a Hazelcast client in Groovy just by puncing in the maven coordinates for Hazelcast and it was a lot like working with the MySQL or mongodb db shells. I think the main problem with Java is the total complexity of the ecosystem, and the fact that it requires wisdom to use well more so than intelligence. Personally I have been bouncing back and forth between Java and other programming languages for years. I was programming it back when it was in beta, and back then it took me about a year of experience to be able to write reusuable OO code that was worth reusing. More recently I got back into with two gigs for companies that had huge maven systems (30+ projects) and it was stressful a while, particularly when a large number of SNAPSHOT version releases, my internet connection was slow, and everything was half-baked. In a situation like that where you have to get on top of everything that's specific to a large codebase, you've got a 20-minute build process, no real project management (in one place the project manager quit the team after she got bitched out by my boss) and, if you're really unlucky, you're the last person to touch the code before it goes to QA, it's stressful. When I went back to coding for my own account, I read the maven documentation from cover to cover on my nook when I was working out at the gym and now my build process is faster than my car can drive the quarter mile and I intend to keep it that way. I think it is tougher for new programmers to get on board of it and a lot of the problem is that companies are trying to look for 10x programmers when they really should be building a 10x organization. For instance, a 10x change can be had by getting a 20 minutes build process down to 2 minutes. It's not science fiction. Sometimes team members and the boss will say that this "isn't a customer requirement" or "you're not being a team player" if you want to speed up the build, but I know the customer wants the job done quickly and the job done right, and speeding up the build process 10 times is the fastest way to attain either of those goals.

yk 13y ago

Unfortunately this is the state of journalism today. In the length of an article it is only possible to make one point, at least outside of a dense article aimed at a specialist audience. Additionally the article should seem to be relevant, that means that its single point need to be exaggerated until it seems earth shattering. And journalists are not really payed to research a topic in depth, but to write articles. So this is at least the impression I get from every article, where I actually know something about the topic. In theoretical physics every article describes one paper, and calls it a break through towards quantum gravity. Independent if this is a cute toy model, a interesting trick to calculate some technical problem or a actual attempt at quantum gravity, in which case there is certainly no data to back up the theory and the theory is almost certainly wrong. Another thing is any reporting about nuclear energy, either the article is wildly exaggerating the dangers of nuclear energy or it is wildly overstating the necessity of nuclear energy. ( Nuclear energy is IMHO a particularly nasty example for articles, because the dangers are extremely model dependent, so to inform a lay audience one would need an entire book.) And for programming, well the wired article did not strike me as a particular bad offender. This would be tolerable, if it would not bias the political process. The current German president, Joachim Gauck, is a nice example. [1] In 2010 the, in this context center-left, SPD had no chance at electing their own candidate, so they attempted a PR coup by nominating a guy who is a hero for conservatives, while the conservative CDU did elect a career politician. Much to the dismay of conservative talking heads. Last year, the president had to resign [2] and chancellor Merkel did nominate Gauck, knowing that now the SPD is on the hook because he was their candidate. And all political commentators in Germany did just dust off their opinion pieces from two years ago. In conclusion, I have no idea how to fix journalism. But I think that better journalism is badly needed. Or else the control loop for the political process has less and less input from actual facts and deep thought and is only controlled by some self consistent PR bullshit. Edit: Clarified the conclusion. [1] In Germany the president has a largely ceremonial role and is elected by an assembly of the parliament and (some members of) the state parliaments. [2] Itself only a media phenomenon.

cgag 13y ago

I feel like people ignore the fact that many of us find Clojure and Scala more expressive and fun than ruby, not just much more performant.

auggierose 13y ago

What's particularly funny is that today, Java is the poster child for performance. I remember when I was giving a talk in 1999 where I said that HotSpot is a game changer, and its lacking performance will not be an issue any more, I was laughed at.

abalone 13y ago

Twitter Engineering recently posted about their move to the JVM in detail. It's worth a read. It wasn't just about a move to a service oriented architecture. They also got well over 10X performance gain out of each machine by moving to the JVM. (They attribute it to better concurrency.) See: https://blog.twitter.com/2013/new-tweets-per-second-record-and-how https://blog.twitter.com/2013/new-tweets-per-second-record-a... I think the article's methodology is fine. It's not about the most popular languages in terms if developer head count. It's looking at what powers the biggest sites.