

The Future's Pretty Cool, or Why I Love Ruby - renaebair
http://intridea.com/2010/4/28/the-future-is-pretty-cool-or-why-i-love-ruby

======
gfodor
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."

~~~
shimonamit
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.

~~~
gfodor
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.

~~~
dhh
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).

------
crazydiamond
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.

~~~
mbleigh
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.

~~~
crazydiamond
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.

~~~
bphogan
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.

------
crazydiamond
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.

~~~
mark_l_watson
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.

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

------
gcv
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.

~~~
steveklabnik
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?

~~~
gcv
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.

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

------
lapusta
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.

~~~
dhh
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.

~~~
rufugee
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.

------
city41
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.

------
mark_l_watson
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.

------
crazydiamond
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.

------
kingkilr
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.

~~~
crazydiamond
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.

------
krschultz
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.

~~~
icey
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.

------
kqueue
Seriously, on HN top 5?

