Friday, September 27, 2013

Rubyists, A Non-Endangered Species

Picture a circle of chairs in a church basement, a small group of people, faces holding anxiety and shame, but also a quiet courage and determination. In the background, a cheap table, a big metal cylinder full of hot coffee, and a stack of paper cups. Everybody's quiet. I stand up.

Me: "My name's Giles, and I read Hacker News."

Everybody: "Hi Giles."

Due to my shameful addiction, which I struggle daily to overcome, yesterday I heard about a GoGaRuCo talk called "Why Hasn't Ruby Won?", and today I learned of a Wired article which will no doubt fuel plenty of Ruby FUD for months (and maybe even years) to come:

Twitter’s engineers came to realize that Ruby wasn’t the best way to juggle tweets from millions of people across the globe — and make sure the site could stay up during its headline moment with the president of Russia. The best way was a brand new architecture based on Java, a programing tool that has grown more powerful than many expected...

Originally, Twitter was one, monolithic application built with Ruby on Rails. But now, it’s divided into about two hundred self-contained services that talk to each other. Each runs atop the JVM, with most written in Scala and some in Java and Clojure. One service handles the Twitter homepage. Another handles the Twitter mobile site. A third handles the application programming interfaces, or APIs, that feed other operations across the net. And so on.

The setup helps Twitter deal with traffic spikes. Because the JVM is so efficient, it can handle much larger amounts of traffic with fewer machines. But the new operation is also more nimble. All these services are designed to communicate with each other, but if one goes down, it doesn’t take the others down with it.

I'm very happy to say I found out about this through a rant which raises the obvious criticism, which is that the article utterly fails to differentiate between Twitter switching languages and Twitter radically overhauling its architecture:

quite frankly the choice of language may not be all that important.

You could take a monolithic application written in any language, break it down so that it scales horizontally across servers and vertically to provide separate systems that communicate with one another in exactly the same language you started with and end up with a system that is… *drumroll* …faster, more scalable and less prone to crashing.

So I don’t buy the line that Java or the JVM saved Twitter. I would bet that a thorough re-architecting of their system saved Twitter. I’d be glad to update this based on Twitter devs first-hand knowledge but I’d already happily put some money on the architecture being more important than the language, it nearly always is.

I've written two books on Rails, and both of them discuss refactoring to service-oriented architecture. I'm writing a third, and the first thing I do in it is give a newbie-friendly demo of one such refactoring. I've worked on a large number of Rails apps, stretching back to 2005, and one very consistent theme I've noticed is that most sites use a more complex, service-oriented architecture than the "omakase" architecture which Rails assumes as its default. (And even 37Signals uses services for some things.)

Nonetheless, the past two days seem to hold a theme of skepticism about Ruby's future.

Time for a history lesson: around the same time Rails first appeared on the scene, proving that you could build a successful company with Ruby, Paul Graham wrote his book Hackers And Painters, which made many programmers aware that you could build a successful startup on Common Lisp (as Graham did with Viaweb). Another terrific company at the time, DabbleDB, demonstrated that you could build a great web app with Smalltalk.

All you really have to do is write good software.

However, if there's any extent to which this Ruby skepticism needs any response, I think the response should be a more honest appraisal of "the omakase stack," or the odd differences between Rails's official "conventions" and the standard deviations from those "conventions" which people who build Rails apps will make, as a matter of convention.

One of the weird things about the Rails community is that Rails's progenitor and overlord David Heinemeier Hansson gives out advice on infrastructure which is very hard to take seriously, and advice on business which very obviously works, yet people seem, to me, to ignore his opinions about business while imitating his infrastructure and finding that it doesn't work for them.

As an aside, I'd like to see people take Mr. Hansson's business advice more seriously. I said above that "all you really have to do is write good software," but really, there's more to it than that. Thinking about business is not always what programmers are good at, but if you want to be free of the danger that you might have to give up your favorite programming language because somebody read a poorly researched Wired article and failed to notice its deficiencies, then all you have to do is write good software, and turn a profit.

But if we're concerned about people with heavy-duty traffic needs taking Rails seriously, I think the Ruby and Rails culture(s) would be wise to acknowledge that most people who use Rails ultimately disregard the "omakase" stack, or at least customize it, in favor of a more service-oriented approach. We can't encourage people to think of Ruby and Rails as the same thing and then complain when they fail to differentiate them, just like we can't encourage people to think that everybody uses Rails the way 37Signals does, and then scoff when they point out that the "omakase" stack is not well-suited for the needs of a business like Twitter (or GitHub, another hugely successful company which uses Rails in the context of a significantly more service-oriented architecture).

Thursday, September 26, 2013

Nobody Will Ever Win

Sarah Mei gave a talk at GoGaRuCo entitled "Why Hasn't Ruby Won?" It's a trick question; I haven't seen the talk itself, but at the end of the slide deck, Mei concludes:

Ruby can't win, because language choices hinge on familiarity. And everyone who walks in Ruby's door has given their brain a different set of training data than you gave yours. So not everyone's going to be a match.

This is a game where there is no winning. But there is definitely losing.

Ruby could wither into a niche language like COBOL or Smalltalk. And none of us wants that.

Daniel Fischer followed up this line of reasoning:

We made our strides, and now we’re receding into history...

We’ve reached a point where the innovation trends are happening outside of our bubble. If we continue with settling with what we have then Ruby and Rails will recede into a comfortable zone and stay around just like PHP...

If you ignore Javascript you’re going to be left behind. Yeah, Ruby is amazing and we’re used to this beautiful syntax but the hard truth is that Javascript is here to stay and if you look at any Rails project that doesn’t take it seriously then you’re in a minefield of hurt. The modern web demands a high command of Javascript. Make your life easier by understanding it and embracing the innovation that is coming out of it. If you take anything away from this post, let it be to compel you to take Javascript seriously.

There's something very amusing about this to me. Last year -- closer to two years ago now, really -- I wrote a bit of a rant called Rails Went Off The Rails, about how I was seeing a lot more creative excitement in the JavaScript world than the Ruby world. Since then, I've been repeatedly heckled by Rubyists who apparently believed me to be a Ruby hater or somebody who had given up Ruby for JavaScript. But now, other voices in Ruby-land are saying the same thing.

Still, I'd agree with Mei that "winning" is a meaningless goal here. Why hasn't Spanish won? Why hasn't English won, or Cantonese, or Esperanto? We speak different languages with machines for the same reason that we speak different languages with each other. I love Ruby, and I think Python's OK. I love Ancient Greek, and I think Latin's OK. It doesn't take a rocket scientist to notice the theme. Languages reflect both culture and taste, both of which are inherently idiosyncratic, and always will be, from now until the end of time.

But I have a harder time with the idea that Ruby is in any danger of withering away. I started working with Ruby in 2005 or 2006, and by any metric, the language has grown. The number of available jobs has obviously increased by a huge degree. Same with programmers and projects. The language itself is faster and more sophisticated. In that context, the notion of Ruby withering away to nothingness looks pretty ridiculous.

It could be fair to argue that the increased popularity of Ruby has made the Ruby community less creative and more boring. There's less excitement and more corporations, or at least, there's less weird creative projects per capita -- there are a lot more pedestrian applications at cubicle-centric companies, sure, but your options for writing code which creates music and art are much better today than they were back in the days of Rails version 0.13. The average Ruby developer today is significantly less likely to be fluent in multiple languages and writing a language of his or her own, but the available tools for language design are much better. So even there, the wither-risk looks low.

I think the only way Ruby could be said to be withering away would be to assume that Ruby no longer holds the center spotlight in the endless fashion show that functions as the closest equivalent to a rational technology selection process for the rampaging herds of aristocratic nitwits who drive a lot of the Bay Area's technology economy. But I've believed for a long time that if you're in a position where you have to care what those people think, you've already lost whatever game you're playing. And sliding from Number One to Number Two in a high-stakes, big-money popularity contest is really not the same thing as withering away at all.

So I'm having a hard time seeing any serious merit to the fear of irrelevance which Mei's slide deck and Fischer's blog post both express. On the other hand, both the blog post and the slide deck (and presumably Mei's talk as well) advocate learning multiple languages, keeping your ear to the ground, and staying up to date on developments in other language communities. This has always been a core value of the Ruby community, and of course I absolutely agree with Mei and Fischer here. Ironically, the fact that this idea has to be explicitly stated is the only sign of Ruby's withering that I've actually seen.

It was the weirdest part of the reactions that I saw when I posted Rails Went Off The Rails back in February of 2012. Perhaps instead of "this has always been a core value of the Ruby community," I should say "this has historically been a core value of the Ruby community," and praise Mei and Fischer for bringing it back.

Friday, September 13, 2013

Dubstep/Chillout Track: Old City Streets

New track by me. Vocals by Veela.

Sunday, September 1, 2013

Privateers In The 21st Century

A theme I've noticed in recent reading:

Asset forfeiture gives cops financial incentives to drum up false charges and seize property from innocent people.

Anti-drug "task forces" throughout the country have very little supervision or accountability, yet receive federal money in proportion to the arrests they make, which functions as another set of financial incentives for the prosecution of innocent people and the seizure of their assets.

Additionally, in Russia, criminals are safe from prosecution for credit card fraud as long as their victims live in other countries. They are especially safe from prosecution if their victims live in the United States.

Meanwhile, a LulzSec hacker has claimed that the FBI used criminal hackers to break into private networks belonging to foreign governments.

For contrast:

A privateer is a private person or ship authorized by a government by letters of marque to attack foreign shipping during wartime... Privateers were part of naval warfare from the 16th to the 19th centuries...

Historically, the distinction between a privateer and a pirate has been, practically speaking, vague... The actual work of a pirate and a privateer is generally the same (raiding and plundering ships); it is, therefore, the authorization and perceived legality of the actions that form the distinction. At various times, governments indiscriminately granted authorization for privateering to a variety of ships, so much so that would-be pirates could easily operate under a veil of legitimacy.