Hacker News new | ask | show | jobs
by jamesbritt 5766 days ago
"Merb was starting to fragment the ruby community as it became a more and more viable option and I did some personal heavy politicking to get it merged back into rails so we could take on the world instead of infighting within the ruby community."

Interesting, if disheartening, perspective.

I much prefer to see greater diversity within a language. I want to see more frameworks, more exploration, more choice. What some may call fragmentation is in fact rich and vibrant and valuable.

And the idea that there is some sort of battle going on among languages, that Ruby needs to "win" against Java or PHP or any language, is truly perverse.

I fear this battle mentality is by no means a minority opinion among Rubyists.

I prefer to use Ramaze for Web development, but I'm glad people can pick Camping or Wave or Wuby or IOWA or Sinatra or any of the dozen other options out there. There are interesting things being done, and not simply so they can be subsumed by some One True Framework.

I was disappointed not to see Nitro get the attention it deserved, to have Chad Fowler tell a conference audience that people working on Nitro should just stop, because "Rails won", was a turning point in how I viewed the larger Ruby culture.

There are many smart, adventurous people doing interesting things with Ruby, but there is also a pervasive cliquishness and neophobia regarding anything that is not somehow tied to Rails.

It's great to see progress made in Rails, but the solidification of Ruby === Rails leaves a bad taste.

5 comments

It's also becoming an issue in the Python world, in job descriptions and among newbies, that Django == Python, as in questions like "how do I implement a sort in Django ?". Not helped by the fanbois who answer "just use Django" without qualification whenever somebody asks which web framework to use with Python.

While I'm happy that Django has helped promote Python, any monoculture is not only bad, but boring.

I really like web.py. It's small, lightweight, does exactly what you need it to do and then gets out of the way.
Can't help but notice the lack of Padrino (http://www.padrinorb.com/) on this list. Granted, it's a layer on top of Sinatra... It's really quite fantastic. Please do look, and run the stack on 1.9.2 :)
I think you completly missed the point of my comment.
you can always press the fork button :)

Also, Sinatra has really become the main competitor to Rails among Ruby frameworks...

    you can always press the fork button 
I have. I've forked my attention to Haskell and JavaScript, among other things.
Personally, I began using Sinatra for new projects fairly recently, mainly b/c I find sinatra + datamapper very elegant. I also love python, fwiw.
It needs to at least compete with Java/PHP ect. In order to create a big enough ecosystem to provide all the libraries and core features needed and keep them up to date. As well as have enough people explaining things that new people don't feel overly intimidated.
"It needs to at least compete with Java/PHP ect."

Why?

And you know what? It never will. Rubyists need to give this up. It's a pipe-dream. Microsoft can set up large/local conferences, charge $75, and make a sales pitch. Dozens of vendors lined up to hand out schwag and pitch their product.

For management, they don't get the best tool, but if it meets requirements, then it's a no-brainer because the most expensive component license is (usually) cheaper than the dev time to meet the basic requirements in-house (those are usually a small subset of what the component might do).

The bigger issue is that that sort of buy vs build scenario manages risk very well.

Ruby has a lot of strengths, but providing a strong story for managing risk isn't one of them. Especially if you don't bill by the hour.

The world of software development isn't winner take all. The same things that can make Ruby and Rubyists great are some of the same reasons it likely won't ever be a good fit for some of the mass-market issues Java and .NET are a good fit for.

That's OK in my book. I die a little on the inside every time someone tries to sound smart by saying "use the best tool for the job" when often there are clear and obvious winners and losers in software. But in this case... Use the best tool for the job. Or maybe just the tool you like most. If Ruby works for you and your company, you're already doing the risk management thing very well. No reason not to use it.

A language community needs to be robust enough to look after these things. This is not the same thing as, nor does it require, "beating" other languages. Even accounting for limited time and attention from interested developers this is not a zero-sum situation.

Language communities do not need to push for a monoculture in tools and frameworks to be robust; cultures that avoid this are much healthier in the long run.

Ruby has a wealth of frameworks, due to Rack. They all have interesting bits... maybe Rails gets a lot of press, but Sinatra, camping, ramaize, padrino, and others would probably like to have a word with you.