A Short Rant At Wired - The Second Coming Of Java
wiggly.org
wiggly.org
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_u...
[2] http://techcrunch.com/2008/05/01/twitter-said-to-be-abandoni...
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.
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.
To make matters more complicated, Twitter publicly abandoned Starling, their Ruby-based message queue, for something written in Scala. People took that to mean they abandoned Ruby and Rails completely.
As far as I know they are still using Rails to generate the HTML pages. If not, it is a recent change.
I think they recently moved that part to the Scala, but it was much later than the other thing.
Compile times are not a reason to move to a service oriented architecture.
> 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.
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.
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.
"If Java rules the web I want to know what Wired are basing their conclusions on, except that it makes a more compelling article."
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.
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.
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...
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.
It may be easier to recruit java devs, but because more people have learned Java, not because it's easier to jump into new projects. That may be a valid reason to pick Java (I've picked PHP in the past, despite preferring Ruby, exactly based on the availability of "good enough" developers versed in the language).
As for the Twitter example, pretty much everything that has been publicly discussed about their original RoR app made it sound like a god-awful abomination in terms of architecture. OF COURSE it didn't scale. It seems to me at least that blaming Rails or Ruby or both is just a convenient way to avoid responsibility for the architecture and/or a convenient excuse for people that wanted to switch to Java/Scala/Clojure to use to justify the rewrites.
I've posted examples in the past on how they could have scaled it using Ruby, based on my own experiences with pure-Ruby queueing systems that would've been "simple" to scale even to their current size. As I've also pointed out, the primary thing they were trying to scale - messaging with potentially massive fan-out - is a well understood and "solved" problem: Turn your flat distribution lists into trees where each recipient is either a follower or the location of a subtree, and you can scale it arbitrarily. In practice, only a very small percentage of their users are "special" enough to require the "tree" treatment, to the point where you can handle it as a special sub-system.
[Heck, you could scale the foundation of Twitter with a bunch of mail servers and shell scripts to manage forwarding lists (no, it would not be costs-effective, but I have done high volume message queueing with mail servers before).]
Note that I'm not saying that another language might not be better for them - at their scale, it pays to optimise things that'd be a rounding error in a smaller environment - but at least their original RoR complaints were ludicrously off the mark. They might very well have valid reasons for switching, but the reasons they used to give were not it.
People try really hard to not accept this, and blame "architecture", but yeah, no.
You can read up on templating benchmarks from the very early days of Rails. You can easily spend tens of milliseconds just in template rendering.
The reason ActiveRecord, DataMapper, et all went with multiple Database round-trips had nothing to do with efficiency for the database and everything to do with Ruby's extreme performance deficits. A language so slow that a few thousand objects, with a dozen fields, and a relation, causing a couple million method calls during materialization would bring the interpreter to it's knees.
And now you've filled your response cycle with forced synchronous roundtrips to external services.
You don't even have the option to think about pure architecture. You're working under real constraints that don't just go away. Everything's got 'em, but the point where you have to start worrying about those kinds of issues in your average app in Scala is 100X later.
> As for the Twitter example... OF COURSE it didn't scale.
> It seems to me at least that blaming Rails or Ruby or
> both is just a convenient way to avoid responsibility for
> the architecture and/or a convenient excuse for people
> that wanted to switch to Java/Scala/Clojure to use to
> justify the rewrites.
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-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.
> More importantly Twitter re-architected their system
> when they found performance problems...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...
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.
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...
This is informally called the Gell-Mann Amnesia effect.
http://harmful.cat-v.org/journalism/gell-mann-amnesia-effect
I don't think it's accurate to say that the news is mostly inaccurate. We just subject material about subject matter we know to a higher threshold of scrutiny than material about subject matter we don't know. We tend to see the inaccuracies as crowding out the accuracies because, thanks to our precise technical knowledge, not getting it exactly right is the same as getting it completely wrong. But to the layman, this is not true. 85% right is not the same as completely wrong and completely useless. 90% right is a good try, not a worthless hack pontificiating about a subject matter he could never possibly in a million years actually understand.
As usual it's all relative. But let's not let our cognitive biases make us too cynical. People generally are trying their best.
Also, I did not mean to say that you should not move to something that inherently runs faster, that would be perverse. However if I have a system written in a language that already works I would probably start by looking at algorithms and architecture before pulling the New Language card.
Once you have a set of interoperating services then re-evaluate which, if any, individual services are my performance bottlenecks that could benefit from the effort of re-implementation in a new language.
The really interesting discussion of course would be one that included engineers from Twitter and their recall about what happened.
I have been in enough design meetings to know that their strategy didn't emerge fully formed from the mouth of one person.
Agreed. But as your article pointed out, Wired apparently didn't want to get into having to do some research. :)
... he said, hoping everyone would accept the statement as fact.
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.
> 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.
THIS!
Many programmers tend to prefer the cowboy style of coding: jump to their favorite IDE/editor and code straight away with less consideration of anything else (productive workflow, etc).
But you're right, the initial complexity (complexity of the ecosystem) to setup a Java project is a world of hurt for people who have limited experience/knowledge vs Python/Ruby ecosystem.
With Java, it's more of a love-hate relationship probably because the language has been around for far too long :).
Love it because it's stable, well-known quantity, have standards (can be a double-edge sword) that many people have to support, and awesome collection of tools and libraries that no other platform/language ecosystems can match.
Hate it because setting things up (IDE, projects, etc) and writing certain part of code could be a bit verbose/more work.
PS: I also go back and forth between various programming languages (JS+Python mostly)
Other problems are deeper: no first-class functions, no tail-call recursion support in the JVM (Clojure has a hack to deal with this), no map/fold/etc. equivalents that can potentially aid with parallelization. I think 1.8 addresses some of these.
Personally, I can live without the modern language niceties. I would really, really like type inference though. Oh, and unsigned ints too.
Java does have its own form of type inference that revolves around Generic functions and once you make peace with it, life isn't so bad. Rather than writing
var xyzzy=new ArrayList<Foo>();
you can write
List<Foo> xyzzy=Lists.newArrayList();
Similarly, the lack of first class functions can be worked around by various means. The Guava toolkit contains map/fold and other functional operations, and when worse comes to worse you can write
for(Thing that:things) fn(that);
In cases where you might be tempted to do something that's more verbose than if you tried to do it the cool way.
There is a lot to like about JDK8 but unfortunately I'm coding to JDK6 these days instead of JDK7 because it's a waste of time dealing with trouble tickets caused by people who are running the wrong Java version and don't know what is going on.
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.
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"
:)