As a note, this isn’t about these specific flaws: It’s that these kinds of flaws are endemic in ruby and particularly rails.

Set Processing

devon@chronos ~/Projects/sets $ cat sets1.rb
#!/usr/bin/env ruby
require 'set'
require 'pp'
large = Set.new(Range.new(1,10000000))
small = Set.new(Range.new(1,10))
pp small.intersection(large)

real 0m35.421s
user 0m23.900s
sys 0m9.910s



devon@chronos ~/Projects/sets $ cat sets2.rb
#!/usr/bin/env ruby
require 'set'
require 'pp'
large = Set.new(Range.new(1,10000000))
small = Set.new(Range.new(1,10))
pp large.intersection(small)

real 0m16.917s
user 0m12.720s
sys 0m3.430s


So the order that I intersect the sets drastically impacts the speed of the algorithm (2x). Let’s take a look at python to see whether a language in the same class behaves similarly.


devon@chronos ~/Projects/sets $ cat sets1.py
#!/usr/bin/env python

real 0m2.583s
user 0m1.850s
sys 0m0.670s



devon@chronos ~/Projects/sets $ cat sets2.py
#!/usr/bin/env python

real 0m2.598s
user 0m1.760s
sys 0m0.710s


So no, python handles the choice of which set to intersect with the other gracefully. This is a good example of how the ruby set api is immature. I’m ignoring that it’s taking between 13.7 and 6.5 times as long to execute, because I think that it’s reasonable for people to do code in something that is easier for them to work in and then optimize. My problem here is that based on the direction you do the intersection, it can take 2x longer in ruby. This is shoddy engineering and is the kind of thing that gets solved in a language as it matures. The problem is that the language was immature when it exploded into widespread use, and no one seems to be doing anything to make it ready for prime time.

So what about 1.9? 1.9 is supposed to be where the energy is going to make the language faster and more mature.

devon@chronos ~/Projects/sets $ cat sets1.rb
#!/usr/bin/env ruby1.9
require 'set'
require 'pp'
large = Set.new(Range.new(1,10000000))
small = Set.new(Range.new(1,10))
pp small.intersection(large)

real 0m13.310s
user 0m11.240s
sys 0m0.680s



devon@chronos ~/Projects/sets $ cat sets2.rb
#!/usr/bin/env ruby1.9
require 'set'
require 'pp'
large = Set.new(Range.new(1,10000000))
small = Set.new(Range.new(1,10))
pp large.intersection(small)

real 0m9.181s
user 0m8.280s
sys 0m0.480s


While it’s faster (which wasn’t really my complaint anyway), it still is very different based on which direction you do your intersection from. I see evidence of speed work being done on ruby, but not on maturing the language so that it meets tried and true engineering principals like the rule of least surprise. (Yes, code is a user interface for coders, so the rule of least surprise applies) (1)

Nil as an object
How about this one that has actually done damage to our database:


devon@chronos ~/Projects/sets $ irb
irb(main):001:0> nil.id
(irb):1: warning: Object#id will be deprecated; use Object#object_id
=> 4


It certainly explains why we have a bizarrely large number of items in our database with foreign keys set to 4. This conflicts directly with the rails standard for naming a database primary key as ‘id’, which you assess on a model at obj.id. Yes, code should have lots of null checks, but real world code has flaws. Sure it throws a warning, but since it doesn’t break on nil when you call .id, you get data corruption. Gee, thanks, ruby.

Ruby in general
These are just a few examples, but ruby is rife with happy path coding. The language needed another 5 years of development before going into widespread use. Instead, I think it’s getting worse because a set of rails engineers who don’t know anything about languages are at the helm, adding lots of syntactic sugar but with a distinct lack of substance behind that candied shell.

_{1. Perhaps it’s not fair to compare ruby to the unix philosophy, because the ruby design philosophy violates the 17 rules in ways that are clearly intentional. Specifically, ruby and rails egregiously violate the rules of clarity and transparency, and rails in particular violates the rules of separation, composition and representation.}

So here goes, my unvarnished opinion of the problems facing the rails community:

1. The community

The community is the single most ego centric community I have ever seen in a decade and a half hanging around the greater free/open source movement. Everyone remembers Zed Shaw ironically (but deservedly) ripping into the rails community for it’s overblown personalities. But numerous other examples abound. How can I possibly view the authors of a monitoring framework with the name God (and a tagline “like monit only awesome”) as anything other then a people with enormously expanded and wholly unjustified egos? How can I possibly take HAML seriously when the main dev‘s bio starts off with “Hampton Catlin is one of the best people in the world. Flat out.” Seriously? One has to know that this guy is going to give any production problem you have very serious attention</wry>

2. Totally decentralized, egocentric documentation

No other way to say it, the rails community is obsessed with personal branding, not with being a helpful community. Is there any centralized site that has a good set of user commentable docs covering most extensions? Php has that, and it’s part of why it’s still a defensible choice for writing web apps despite its numerous other flaws. The end result is that when you google for just about anything having to do with rails code, the first five items are all personal blogs

With rails, the community doesn’t build any sort of centralized corpus of knowledge, what they all do is write a blog entry about such and such technique, or how they fixed a problem. The problem here is that nearly all of this knowledge is outdated, and impossible to tie to any one version of the application stack. So instead we get tons of blogs with disjointed suggestions that take you in the wrong direction whenever you google about an issue (sure, this solution worked in 2.1, but not in 2.0 or 2.3). Too bad it’s in a blog without with the applicable version number instead of in a comment at the end of the documentation like mysql or php.

3. Excessive reliance on ORM

I’m sure you have all heard of the N+1 problem. Sure, lots of devs will tell you that it’s simple to avoid, but based on all the teams I’ve evern worked on, all it takes is one lazy programmer and all of a sudden your templates are taking 7000+ queries to render. It’s no wonder the rails community seems to think sql is slow. Hint: the answer isn’t memcached, the reason your rails site is slow is because the sql it’s running is craptastic. 99.999% of rails sites could be vastly improved by just hiring one or two people who actually understand relational databases. The part that I really just don’t get is that sql is much easier then coding, and RDBMS is not rocket science, but it’s treated like this big hideous bear that your developers have to hide from.

4. Pure ruby is the answer to everything

The community is utterly obsessed with pure ruby, and looks down on impure extensions that are wrappers around solid C libraries. This results in a general race to the bottom for speed, stability and maturity. The unix world is packed with easy to integrate, solid libraries. Libxml-ruby is nearly two orders of magnitude faster then rexml, and has top notch compliance with the xml spec. Yet somehow rexml is the standard and libxml-ruby is the red headed step child.

5. Fragile ecosystem

Now, I’ll be the first to admit that the rails maintainers shout far and wide that rails isn’t enterprise ready, and it really truly is not. Over and over I have gotten bitten by the myriad of flaws in the rails ecosystem. Any one specific issue I’ve dealt with could have been fixed in version such and such of some gem (or it’s even worse with rails plugins.) This complaint is not about specific flaws so much as the whole ecosystem feels like it’s standing on a very fragile foundation. Some examples of the ways we have gotten bitten over the life of the multiple rails projects I have been involved with are:

• rexml violating the xml spec by totally ignoring the encoding of documents parsed by it.
• gem silently failing (not returning the proper unix return code) and thus allowing some of our instance launches to blow up without a reasonable way to catch it. (And as a note, when you have to automatically install large amounts of gems from rubyforge, it chokes a *lot*).
• Innumerable gems regularly break api compatibility even in minor releases (I’m looking at you Rack). When you add calls, you can’t just remove them between 0.9.2 and 0.9.3, it’s damn unprofessional.
• i18n has been a real problem right from the beginning.
• Passenger’s ApplicationPool choking and never coming back, forcing you to restart apache once a month
• Constant movement from one webserver to another. It’s damn frustrating to have to switch web servers every 3 months as the community hops from one the the next, as everything else gets filed in the community folder for utter crap. At that point it becomes damn hard to find support for problems. First it’s lighttpd, with mongrel, then thin, then nginx with thin and on and on. Somehow people need to support this mess. Apache works, is well supported, can be very lean, and basically every systems person on the planet knows how to work with it. Hint: as a programmer, it’s not all about you. Your applications need to be supportable; running away from standards for the sake of being different is dumb.

And just to reiterate, some of these could be actually fixed, or hell, they may have always had a *way* to work right, but the default was broken, and caused project problems that never should have existed if the rails community could ever get around to implementing a spec as it is written.

6. Generates bad, bad habits in devs
• Creates a view of the world that implicit is good. This goes all the way to the language itself and the silly fact that explicit returns use more processor power then implicit returns.
• Creates a view of the world that clever is good. Anyone who has maintained software for a few years should be able to tell you, clever is bad, very bad.
• My personal least favorite, the technological abortion known as Single Table Inheritance. Admittedly, even the community is now arguing for people to not use this. STI is a wretched way to bind a database with an object model, it encourages sparse tables as well as overloading of tables. Both of these things will bite you in the ass down the road.
7. Convention magic

Magic is the core of rails, and seems to be one of it’s biggest selling points. The problem is, there’s simply no place for magic in a world where people need to actually support your code. Explicit configuration and code is much more useful to operations folks who aren’t familiar with the codebase, framework, and language. Even if you use your developers to support your app, when they rely on a bunch of clever magic it can make for longer outages while people have to figure out what implicit thing they are failing to take into account.

8. Rails hype will kill ruby

Ruby could be a decent language. It has a lot of awesome things going for it. In a few years it really will be ready for real heavy lifting. At least that was ruby’s future. Rails has taken over the show. The Rails community is the ruby community, and it has not set ruby on a course to be a truly dependable language. Instead as rails project after rails project fails in all sorts of business environments, it is creating a permanent bias against the language in the management staff that oversees projects in american business. I’ve personally seen it in multiple companies, and expect to see it in most shops that are today fiddling with rails.