My web provider updated my server, which meant re-deploying my website, which in the case of rails is such a massive (and growing) pain that I decided I'd be better off writing a whole new site in Django.
After the second time that I updated to the latest version of rails, perhaps late 2010, I’d decided I’d had enough. For someone who has a job writing a rails app and maintaining it and uploading it to servers, I’m sure the minor headaches that accompany the upgrade procedure are more than made up by the gains in a better API, or other benefits. However, for someone who just runs a weblog and has to upgrade every now and then, getting a new version of rails up and running is a small nightmare.
Every time I think of ruby I keep coming back to this smarmy message from someone high up in the ruby community venting about Debian splitting packages rather too finely. This kind of holier-than-thou approach probably works for newly minted acolytes, but for someone maintaining a system, or trying to install appropriate packages for ruby and rails, it’s a fucking pain. And I’m over it. I don’t care that I like the core language itself more than python, because ruby guys are fuckwits.
I don’t care about the elegance inside the language itself, because everyone who writes in it doesn’t take the time to think about how the tool will be used, and instead focuses on saving themselves time. I’m no longer interested in the active community, because every new version of ruby leaves older versions to die, doesn’t think through new features, and re-invents the kitchen sink because hacks upon hacks have left a reasonable kitchen sink unusable by the community.
Take a look at linecache19 for instance. From what I can tell, it’s trying to do things it shouldn’t be doing, and in short that means it breaks on very many versions of ruby. Rails 3 needs a very particular set of ruby versions to work correctly. If “gem” wasn’t a crazy kitchen sink application already, there’s now “rvm”, which encapsulates an entire ruby environment so that it won’t conflict with other ruby environments on the same machine.
As for rails, the DRY (Don’t Repeat Yourself) principle is bullshit. It should be telling that you have to repeat what “DRY” means every time you use it. Using the rails scripts to generate your directory tree would be great if it worked reliably across versions. Unfortunately, it doesn’t, and migration stuff it might have has a finite chance to fuck your software. Maybe in 2010 I was more patient, but I just don’t have the time any more.
So here’s my new attitude: Fuck Ruby, and Fuck Rails.
Put it on a t-shirt. Sing it from the rooftops, because everyone hacking on Ruby, as smarmy and self assured as they are, have fucked Ruby and Rails. And just in case you thought I forgot about the python guys, I didn’t. You’re the same, but at least I can apt-get django and it works.
I went to actively investigate static blog generators, to the point of trying to write an initial site for it. Then I noticed something interesting about static blogs: No one updates them. There’s a simple reason when you think about it. The “database” is now effectively kept on your machine. In order to update a static blog, you need to either be on the machine with the templates and unformatted content, or you need to keep it up with your service provider. In either case, putting new content on the site is a big hassle, and I can see the site becoming a crystalline tomb if I used a static blog generator.
So this leaves me right back at the beginning. I’m going to try and make a go at Django and see how it goes, but considering the similarities with Rails (and the parallels between the python and rails communities) I don’t expect much. I do know one thing: I’ll never read those sneering blogs at PHP the same way again. PHP does suck (really really badly) but Rails sucks harder at deployment.