The Future's Pretty Cool, or Why I Love Ruby | Hacker News Reader

The Future's Pretty Cool, or Why I Love Ruby

intridea.com

58 pointsrenaebair64 comments

Of course, this cuts both ways. The Ruby community is infamous for being, for lack of a better word, ADD when it comes to frameworks and tools. What's cool this month is un-cool the next, when someone else comes along and re-invents the wheel with different names & syntax. Going back and trying to reconjure up some old Rails code I wrote a few years ago is basically impossible, as the plates have shifted underneath it so much as to make it a huge project in itself to bring it up to the present day toolchains.

Beyond this, I see communities obsessed with tools and frameworks as distracted. The hard problems are those of algorithms, data structures, design, and architecture. Most of the things that we see a lot of programmers spending their time thinking about, writing about, and writing code for fall under a class of problems that, while important and necessary, often seem to me as those under that oft cited line in most academic papers: "a simple matter of programming, left to the reader."

Thank you. As a Ruby on Rails programmer I couldn't agree more. Rails 3.0 will bring some maturity... programming to interfaces and APIs rather than implementations. I believe Javaland "got that" a long time ago.

Agreed. Rails 3 seems to be shaping up to be the "revenge of the grown-ups". I see it as potentially being as paradigm shifting as the initial release of Rails, but not as in-your-face.

When Rails came out, it reminded us that programming can be fun. Rails 3 will shows us that not only can it be fun, but it doesn't have to come at the cost of stable interfaces, reusable code, and the ability to not have to go back and refactor your entire project every 6 months.

Thank you Merb people.

I think it's awesome that you're excited for Rails 3. I'm incredibly excited for it. Lots of great stuff happening.

But. (And that's a big but). I think you might overestimate the philosophical changes that are going on here. Seeing pipe dreams and unicorns where there are simply just incrementally improved ideas and work horses.

The rate of improvement in the Rails camp is not going to change because of anything fundamental to Rails 3. It might change because we're running out of big problems to deal with, but I also somewhat doubt that.

So that means that yes, you will have to change your application every 6 months, if you want to keep up with the latest and greatest. But you don't have to. You never had to. A Rails 2.3 application, for example, could have been chugging along just fine for the last 12 months (2.3.0 released March '09).

If only the language itself was on the same solid footing! I love Ruby on Rails but I see most of the uncertainty coming from broken Ruby 1.8.7 and 1.9 builds -- Rails changes just add to the mess.

Rails 3 + Ruby 1.9.2 should be fine.

I only did a tiny bit of work with Rails 1.2, and basically got serious during the 2.3 days... but is most of your old code really not compatible? I specifically remember watching a presentation by DHH where he talked about how old Rails code he looked over _looked_ a bit dated, but still worked just as well. He mentioned this specifically with the new RESTful focus that came along, many people were going up to him and asking "I have to re-write my entire app to be RESTful!" and that's just not the case.

There's still a bit of social pressure to "keep up with the Jonses", though, I'd agree with that. But it doesn't mean you have to do it.

The talk was Living with Legacy Software: http://www.youtube.com/watch?v=CJkiCpPeYuI -- from RailsConf EU '08.

There are definitely things that broke along the way in Rails. However, the overall problem is that the 2 or 3 dozen gems or so that were coupled with this project of mine all had incremental releases that broke existing APIs. And new dependencies were introduced. And so on. Basically bringing an old project up to the status quo was an exercise in frustration, so I just worked with my old gems, bugs and all, since it was less scary to do so since my test happily passed in their frozen-in-time world.

Note my post here was partially devil's advocate, since, as bphogan said above, having a vibrant community inventing new things (with a lot of extraneous wheel-inventions accruing along the way :)) is infinitely more desirable than a dead one, set in their ways and so on. I just wanted to throw up a counterpoint that this enthusiasm for the churn needs to be tempered.

I think basically the Ruby community is what you get when developers are given a fun to use language and throw caution to the wind and just build. This is great, but it's time to tilt back towards future-proofing a bit, as the Rails 3 initiative has shown us. It kind of reminds me of the typical successful project: lots of initial, quickly built prototypes created not to sell but to learn, followed by one or two more solid, grounded, mature and thought through production releases that are meant to last years, not months.

Yeah, I generally have gems locked into a particular version, and try to only update when I actually have to. I'm also still using ree, I plan on just doing the 1.9.2 move at the same time as the Rails 3 move.

> I just wanted to throw up a counterpoint that this enthusiasm for the churn needs to be tempered.

I think this is a valid point, but I also really enjoyed David's comment above. This 'never being content' aspect is one of the things that I really _like_ about Rails, and probably why the community gets a reputation for being a bunch of angsty teenagers. It's important not to get rid of that fire and desire to make things better.

I agree with this completely. I just wanted to add though that had I stayed with Oracle and PHP / Java, I would not know the things I know now, nor would I have had the opportunities that I found because of those. Ruby (the community) has challenged me time and time again not to dismiss something just because it's new or different. I say that because I still talk to coworkers and former coworkers who are still doing what I did. They don't know about NoSQL, they don't know about load balancing, or metaprogramming, or evented Javascript, or any of the things I've had to become aware of to do my job. (Or HAML and SASS which are just fun and awesome).

I see far too many people getting comfortable and then becoming dangerously close to being out of date.

I don't like the distractions of "new shiny" every week, but the stagnation of a community scares me even more. So I strike a balance.

What I would like to see is more involvement from people who claim to know what they're doing to join our Rails Mentors project (http://railsmentors.org/) Then they can teach people, instead of waving hands about NoSQL and leaving it up to "an exercise for the reader."

(Disclosure: I am the coordinator of the Rails Mentors project. It's non profit and part of RailsBridge (railsbridge.org)

This is a very shallow analysis of a fast-moving community, but I can sympathize how it's the easiest way to make yourself content with using the same tools as you did three years ago. If you feel like you're getting stuff done to the best of your abilities with your current toolset, enjoy!

The Ruby and Rails community is lead by individuals who are never happy with the status quo. There are always things that bugs me about development. As soon as I solve one problem, the next in line gets promoted and I work on that. I find that incredibly rewarding.

It does come with the cost of blink-and-you've-missed-the-bleeding-edge. Which I understand that not everyone has the mental bandwidth (not as a sign of intelligence, but as one of priorities) to keep up with. That's OK. You'll still be better off with just taking a snapshot of the state of the art every 9-12 months than just tuning out.

Also, you're setting up a false dichotomy between caring about the tools and the domain. The vast majority of developers I've found that can't help constantly improving their toolset is the same kind that can't help improving their understanding of their domain. In fact, one often leads to the other. I've created lots of Rails features that were directly related to a deeper understanding of the project domain, for example.

I love Ruby. I love Rails. I don't love that Rails 2.2.2 doesn't work well with the version of Ruby Gems 1.3.6, which I have to have on my machine for my Rails 2.3.4 projects. Can I just upgrade the 2.2.2 project? No because it's not mine...it's a client's project. etc... This happens to me all the time.

The problem isn't mental bandwidth. It's more along the lines of the "Consistency-Atomicity-Partition Tolerance" debate related to databases and the noSQL movement. Perhaps it's the "Creativity-Velocity-Supportability" triangle - Ruby/Rails leans toward the "Creativity/Velocity" - it's fun to use, the community is very creative and the framework moves fast. It's harder to support old projects as time goes by because the framework moves on and old projects break.

I'm consciously choosing the higher supportability cost of older code because of the fact that I love writing code with Ruby and Rails. It's still a cost I have to be aware of when I start a new Rails project.

EDIT: I reread the comment and I retract "This is a subtle ad-hominem attack on someone making a very legitimate point about the community."

When I first read it, I thought that he meant "mental bandwidth" and "shallow" as attacks and i can see he wasn't implying it that way...

This is a subtle ad-hominem attack on someone making a very legitimate point about the community.

I think you've got it backwards; DHH gave a very legitimate response to someone making a subtle ad-hominem attack on the Ruby community.

Instead of addressing the rapid evolution of the Ruby community on its merits (or lack thereof), the phenomenon is reduced to "ADD," "distraction," and an obsession with coolness.

There couldn't possibly be any merit to, for instance, embracing Git or REST: we're all just trying to be cool. "Very shallow analysis of a fast-moving community" is right on target IMO.

Agreed. I re-read it and agree DHH's response is legit. However, I don't see the original comment as an attack on the community as much as a (warranted) critique of the community being over-focused-on and at times distracted-by, 'cool'.

That's not what ad hominem means. Ad hominem is when you disagree with an idea because of who supports it. For example, "gun control is a bad idea because Hitler believed in it".

No, it's not. Ad hominem is when you argue that something wrong with the person invalidates the person's argument. http://en.wikipedia.org/wiki/Ad_hominem

That's an association fallacy, not an ad-hominem.

http://en.wikipedia.org/wiki/Association_fallacy

Ad-hominem is where you use qualities of the arguer as disproof of the argument.

> Ad-hominem is where you use qualities of the arguer as disproof of the argument.

Right, which is what he didn't do. "I don't like Rails because DHH has an ugly hairdo" would have been an ad hominem. In this case, he is disagreeing with the idea itself.

No, that would have merely been an ill-informed opinion and a non-sequitor. One can feel however one wants about a subject and for any reason and still not commit a logical fallacy because feelings are a-logical. For an actual fallacy, we need actual premises: "Ruby is good," "Rails is bad," etc.

An ad-hominem is even more specific. The premise must be disputed because of the arguer. So, if DHH makes statements about Ruby or Rails, and one argues that those statements are false because of DHH's hairdo, then that would be an ad-hominem.

FWIW, see RVM, which lets you painlessly manage multiple Ruby versions on a system, even on a per-project basis:

http://rvm.beginrescueend.com/rvm/basics/

Agreed, it basically solved the having a really old rails and a really new rails on the same machine issue.

Honestly have rails 2.2.2 and old rubygem, along with rails 2.3.4 and rubygem 1.36 has never been easier. Thanks goes to the RVM project for simplifying keeping around different stacks of Ruby.

I wrote a gem in ruby a year or so back using 1.8. When 1.9 came out, it was extremely easy to port it.

OTOH, I've been hearing that people have written books for Python 3 which hasn;t taken off. Now they are backporting their books to 2.x (e.g Dive into ..).

There is a negative side too. Everyone's writing gems. There are plenty of gems floating around, some incomplete some abandoned, its hard to tell. When i worked in Java years back, aside from the Java distribution itself, i used to use libs from jakarta.apache. One knew they would be maintaining it, and the quality would be good.

In Ruby, i really don't know of any such company or initiative, that maintains libraries. It's too open. I get frightened when i download a gem which has many dependencies, since sooner or later some deps are going to break. That's happened several times. Even some of the well-known rubyists abandon their gems and don't respond to mails or bug reports since they are busy in ruby confs, or setting up their startups.

Then there's the gem creation process, which seems to be changing. I typically tend to google (maybe this is my fault) and i get outdated docs on creating a gem or publishing it. Hopefully, the ruby-lang.org site has an updated link on suggested or preferred way to create a gem. Every time i create a new version of my gem (it uses hoe), it seems hoe has changed, and I struggle to find a sample to correct it.

However, I love ruby too.

I don't use Ruby very much, so I can't respond to the bulk of your comment, but I wanted to note that Dive Into Python was first written for Python 2.x, then rewritten for Python 3, not the other way around.

http://en.wikipedia.org/wiki/Mark_Pilgrim#Dive_Into_Python

I didn't contradict your statement. Going by the discussions on this site on another thread, it seems that the Python 3 book is being backported. That only means that exercises/examples in the 3 book are being back-ported - perhaps they will be added to a new edition of the 2.x book.

You should really take a look at Jeweler (http://github.com/technicalpickles/jeweler) and MG (http://github.com/sr/mg). They both make it extremely easy to maintain and publish gems to Gemcutter. Hoe was necessary back when RubyForge was the only gem host, but now that we have gem push it's not the simplest way.

The other day while creating a new version for my gem, and getting hoe errors, i did look at the link above. It did not look so easy. Instead of creating a gemspec, or modifying my gemspec, i update the Rakefile and then generate a gemspec.

I will try it out and see how it is.

Again, should not ruby have one standard prescribed way of doing it, and not so many.

Ruby does. Jeweler, Hoe, and other things are scaffolding for Gems. They get you going, but I found that as I relied on them too much I didn't really understand how it works. You can write a gemspec by hand which is what I have done now for my new gems that I'm working on. When I get time I will change the old ones to use a hand-rolled gemspec and a simple rake file for publishing.

Gemcutter has made it trivial to take a hand-rolled gemspec and publish your gem. No libraries or gem scaffolding necessary.

I don't really understand the need for Jeweler. Gemspec is a straightforward format and I've never had problems maintaing a gemspec by hand. It provides a version bumping rake task, but that is a single line edit in the gemspec.

I agree that gem releasing used to be cumbersome, but the new gem creation process is redunkulously simple:

1) Signup at rubygems.org: http://rubygems.org/sign_up 2) gem build my_lib.gemspec 3) gem push my_lib.gem

That's it!

We should be doing something for all those gems which are abandoned or not functional, and also dead ruby projects which have not released code for years.

It makes it very hard to search for a given gem/library -- one has to wade through too much noise. The reason I've stopped downloading perl apps is the same -- many of them depend on some broken, abandoned library -- you waste hours trying to install something before finding some conflicting/broken dep.

Perhaps a repo or listing of live projects, with some rating system.

Now there is new problem: not knowing if a gem is for 1.8 or 1.9.

http://isitruby19.com/

Does this not depend on someone updating it. I find in many cases just a gem name, nothing more (last i checked).

It does. So if you find just the name, try it out, and then report back, so the next person doesn't have the same problem.

THis still involves many steps for someone looking for a library or gem that already does what he is looking for. 1. Do a search on rubyforge/google etc 2. Go through list to see what has actually released code 3. Check isitruby.com to see if someone's commented on it 4. Test out and then comment on isitruby.

if it does not work, there could be other reasons as well as for example, a dependency not installing on my machine.

In fact that brings up another point. What if the given gem has more dependencies. I would have so much to test out just to know if it works on 1.9.

I would think it is best that the author declares he has tested it on 1.9 on a given OS. Then others can add their feedback whether it has worked on their OS etc.

The 1.8 and 1.9 dichotomy is a pain, no doubt about it.

I totally switched to 1.9, wiped 1.8.* from my development systems. In a few cases I had problems (like manual edits to acts_as_list) but life is simpler and the runtime speed increase is really nice. Pardon a link to my own stuff, but I have written about the 1.9 conversion: rubyplanet.net

I am trying to maintain Ruby 1.9.1 and JRuby compatibility on my rails apps which is getting easier to do.

I would be completely on Ruby 1.9 right now if not for Redmine. :(

The challenge with getting those old gems up to snuff is the challenge with Ruby itself. Unless you have a great set of test cases, refactoring is a REALLY BIG PAIN...often with a cost close to 10-20% of original development in my experience.

In my many years of doing Ruby development, that's my real complaint. Ruby makes it much more difficult and costly to eliminate technical debt.

Would you mind explaining why Ruby makes this harder than other languages do?

The reason that I ask is because I've found the opposite; due to the massive number of easy to use testing frameworks, it's easier for me to end up writing tests and making sure my debt doesn't come back.

Because of open classes and code generation in general, it's very difficult to track down to the exact line of code where a feature is introduced, or changed. Add to this that code tends to be decorated in a very non-traditional way; it is typically just re-opened and modified to fit the developer. Add to this the fact that you may have many gems installed, and each of them may do this re-opening, and it becomes a refactoring nightmare, because you really don't know at any given time where all of your behavior is coming from.

In one specific example, we had a bug in moving an app to 2.3 in which three different gems contributed. It was very tough to nail down.

Aside from all that, pop open your favorite editor or IDE, find a method you're interested in learning more about (let's say, for refactoring), and try to use that tool's built-in functionality to "Go to" the declaration. 6 out of 10 times I bet it fails to get you there. I have tried with RubyMine, NetBeans, Aptana, and Vim, and each of them fail to find anything more complex than simple method declarations. Ruby is just a hard language to navigate.

> Because of open classes and code generation in general,

Gotcha. Makes lots of sense. I've just not been bitten by this yet, I guess.

> use that tool's built-in functionality to "Go to" the declaration.

Ah, I'd never run into this too, because I default to just going to a browser and going to the online docs. But if you're used to another workflow, I can see how that'd be a pain.

Why I don't love Ruby:

Ruby 1.8.6:

    require 'set'
    [[5, 6].to_set].to_set == [[5, 6].to_set].to_set
    => false

Meaning, two identical objects are not equal. This is fixed in 1.8.7, but:

Ruby 1.8.7:

    require 'set'
    [2, 3].to_set.hash == [4, 5].to_set.hash
    => true

I understand hash functions can produce collisions, but they really shouldn't collide for something as trivial as [2, 3] and [4, 5].

Broken semantics for such simple things make me seriously distrust the language runtime completely. At the very least, this means that the much-touted Hash object in Ruby is untrustworthy and can easily lead to data loss or corruption.

As you say yourself, 1.8.6 is slightly broken. But do you expect old releases to always be bug-free? 1.8.6 isn't even the newest version of the 1.8 branch, let alone that 1.9 is the current branch of Ruby.

And as for your distrust of the runtime, did you know that 1.9 is an entirely new one?

As I noted, 1.8.7 produces a hash collision for [2, 3] and [4, 5]. 1.9.1-p376 has exactly the same behavior. I reiterate: the Hash object is unreliable, regardless of the runtime version. Based on such nasty behavior in such a simple case, I distrust Ruby's runtime and standard library for more complicated uses.

Gotcha. I misread that part. My bad. I don't use sets, so I've never encountered this.

> they really shouldn't collide for something as trivial as ...

Why not? Hashes produce collisions. If you don't want collisions don't use hashes. Or if you want a hash function that doesn't produce collisions for your specific data type, write one. It's not hard.

Relying on a generic hash function to never create a collision is just poor engineering on your part.

Ruby painly needed a milestone of stability. Ruby's market is Rails, and while I admit some projects(JRuby, IronRuby, Ruboto, Macruby) trying to explore other possibilities, they haven't got much further than exploration. So what's up with Rails? It's market won't be growing:

1. Django/Grails/Symfony/ASP.NET MVC are closing gaps in Python/Java/PHP/.NET communities, making RoR not as much attractive as it was couple years ago. Means much less new developers form these communities.

2. Today's start-ups are moving to RIA, where the UI is built via Capuccinno/SproutCore/GWT/Flex and Rails doesn't provide much benefit here compared to others.

3. Ruby hardly can fight with Python and PHP on their markets.

I admit Ruby influence and innovations, but I won't put my bets on it.

Do you really see many startups moving to RIA? Maybe it's because I'm from Hicksburgh, but I don't know of one company here that's doing anything serious with RIA. We even have one guy doing an 'embedded' HTML5 app, using <video>... Most of the websites that I use aren't using RIA, either. Am I missing out on a big trend?

And why can Ruby not "fight with Python and PHP on their markets?" Care to elaborate a bit?

>fight with Python and PHP on their markets?

PHP has lots of opensource web-apps: OpenX, Wordpress, Joomla, Drupal, phpBB, SugarCRM, Magento eCommerce, MediaWiki you can just download and run on any hosting in couple of minutes. Every app has a community behind it. Haven't heard about anything as popular built with Rails(except Redmine).

Python - studied in Universities like MIT and can be found in any UNIX/Linux distribution. Lots of bindings and libraries(SciPy, NumPy, Twisted). Ruby bindings and libraries are far behind.

Gotcha. I would agree about PHP, but not much about Python. It's true that universities are starting to get into Python, and not so much ruby, but bindings and libraries? I guess we're just trying to accomplish different things.

Maybe, I was evaluating Ruby for my university tasks even before Pyhon, but found a lack of good GUI and Plot/Math libraries.

What laughable and superficial conjecture.

1) It's great that the ideas that Rails popularized are being adopted on other platforms. But besides for Django which has a) been out for almost as long as Rails and b) uses a great dynamic language, the other camps you mention doesn't have anything resembling the "Ruby on" part.

Just grabbing the grabbing the general ideas of Rails are trying to fit them into less expressive languages yields some less than desirable results. Have you actually looked and compared any of the code back and forth?

2) Hahaha. The web has been pronounced dead on more occasions that I can count, but RIA has been the boogeyman since the beginning of the last decade. Don't invest your piggybank in it happening this time.

Additionally, I know of lots of Rails apps that are using all those technologies for the front end. Whether your output is HTML or Flash or whatever, you're going to need a backend to handle it. All the benefits of Ruby, Active Record, Action Mailer, and the works are as relevant as ever with that.

3. What does this even mean?!

Anyway, good luck betting.

I've done some professional development with Symfony and Grails. Both close to RoR(Grails even better in my opinion). I also use Python as my scripting language, and tried Ruby/RoR, but it didn't fit my needs.

I'm language agnostic, but you must remember that other languages evolve too. PHP got namespaces and closures, C# - some dynamics, and Groovy - support from SpringSource/VMWare and is most popular language on JVM: Jython, JRuby, Scala - all far behind.

In general, I agree with you. However, Rails' influence on other platforms has yielded some great projects. My current favorite is play (http://www.playframework.org). It's almost a one-to-one feature port of Rails to Java, but actually manages to do it in a way that works very well and very pragmatically. I'm at least as productive in Play as I am in Rails, and that's after many years of Rails development.

This is also Ruby's downfall, and until the community can settle down a bit, why Ruby will never be a mainstream language.

I enjoy Ruby, I tend to write my scripts in it, and have written a couple Rails sites in my time. But there's probably 1 Ruby job out there for every 300 .NET and Java jobs, maybe even less. Maybe the Ruby community likes this, I dunno. But for me, it means I've never had a chance, and probably never will have a chance, to really use Ruby in a professional environment.

And I can't really blame companies, if I had a company I wouldn't use Ruby either. I generally find .NET is a nice compromise between Ruby's ADD and Java's glacial pace, but that's just me.

Nice article. I have moved on from 1.8.x and just use 1.9.1 for just about everything except when I need to use existing Java NLP and Semantic Web libs, in which case I use JRuby. I have an ongoing infatuation with Clojure and Scala, but Ruby is my go-to language for getting work done.

Another reason to love ruby is the great community. The ruby-forum has leading ruby programmers helping out newbies. No one's berated for asking newbie questions.

I am not saying that other languages don't. Java has wonderful JUG's.

Loving a language on account of things that have nothing to do with the language seems kind of weak to me. I love the people, communities, and tools that surround python, but if they all disappeared tomorrow I'd still use it.

I think you were replying to my last line. I only added that since I had mentioned some gripes and i wanted to avoid someone getting upset and saying "if you don't like it, go elsewhere".

I have my reasons to love working in ruby, most of all is probably how easy it made my work. I have come from other languages which i initially loved but then found too verbose and cumbersome and sort of strait-jacketing. That there are some issues with ruby (such as repositories, or obsolete gems -- a problem with perl and other languages too) should not make me dislike it. Cheers.

There is some irony in using GitHub as a shining example of Ruby consider that the tool underlying it all is written in some hardcore C.

He didn't use GitHub as a shining example of Ruby. He said the community embraces it, so he's had exposure to it as a result. CouchDB isn't written in Ruby either, and he mentions that too.

Seriously, on HN top 5?

Reply on news.ycombinator.com